08/09/17 03:04:21
>>142
The controversial phishing issue may be resolved by the following mechanism.
With a prescribed mark embedded in a page (like RSS), a Relaying Party (RP)
notifies the user and browser that they may be authenticated by OpenID.
The user always types in a URI, along with his ID and password, on the
same page of an OpenID Provider (OP). The URI points to a page on
the RP site, and is expected to be automatically entered by implementing
a login button or the like in the browser (until then, it has to be bookmarked
or manually entered).
The OP provides the browser with user-identifiable information (such as
cookies).
It also informs the RP site that the user has been authenticated, and
transfers to it the ID, registered date/time, and identifiable information.
Because the uniqueness of the ID may be merely guaranteed on the OP
site, the ID entered by the user (local ID) may differ from that announced
globally (global ID) (to cope with spam attacks).
To log in, the user does not have to remember or type in his global ID.
The temporal-based uniqueness of the ID can be assured by a domain
owner who keeps tabs on the date and time when the user starts the
authentication service.
This allows for reuse of limited resources, while ensuring the singularity.