[security] User directly requet to OP.

6d5930fcb2225bbca791076ca6b84ce5 at x.je 6d5930fcb2225bbca791076ca6b84ce5 at x.je
Wed Sep 17 04:30:22 UTC 2008


Nice to meet you.

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.

Old browser(manual):
1. User -> RP    request page
2. User <- RP    return page including OpenID mark
3. User -> OP    request login page
4. User <- OP    return login page
5. User -> OP    request jump page with local ID, password, URI
6. OP -> RP      notify authorization with global ID, date, cookie
7. User <- OP    return jump page including cookie
8. User -> RP    request customized page with cookie
9. User <- RP    return customized page

New browser(automatic):
1. User -> RP    request page
2. User <- RP    return page including OpenID mark
3. User -> OP    request login page with URI
4. User <- OP    return login page including URI(hidden)
5. User -> OP    request jump page with local ID, password
6. OP -> RP      notify authorization with global ID, date, cookie
7. User <- OP    return jump page including cookie
8. User -> RP    request customized page with cookie
9. User <- RP    return customized page

The original text was written in non-English.
Mr. 159 translated it almost.
His work is excellent than mine.
The poor sentence is my work:-P
Please forgive pooh English.
Thank you.



More information about the security mailing list