[Openid-specs-ab] Proposed new text for 2. Authentication

n-sakimura n-sakimura at nri.co.jp
Wed Oct 30 05:03:13 UTC 2013

IMHO, like I have provided the text in my comment, it would be good to
give the developers the idea that ID Token is used to convey the
authentication result from the server to the client. We should say that
in the paragraph as well.

Also, it is noteworthy that we are not doing Authentication per se, but
we are federating / conveying authentication result from the
authorization server to the client.

So, I suggest something like this:

    2. Authentication

Authentication is typically performed to log in the End-User or to
determine that the End-User is already logged in. OpenID Connect carries
the result of the Authentication performed by the Server to the Client
in a secure manner so that the Client can rely on it. For this reason,
the Client in this case is called Relying Party (RP).

The Authentication result is conveyed via a secuirty Token called ID
Token. It has Claims expressing such information as the issuer, the
subject identifier, the timing when the authentication was performed
etc. of the security token. Refer to section and for
more details.

Authentication Requests can follow one of three paths:

 1. the Authorization Code Grant (response_type=code)
 2. the Modified Implicit Grant (response_type=token id_token or id_token)
 3. the Hybrid Grant (other response types defined in [Multi-Response])

Following is a non-normative table expressing some guidance on which
grant to chose among the above three.

Conditions / Requirement 	1. code grant 	2. modified implicit grant 	3.
hybrid grant
Server is not directly reachable from the client 	
Want less round trip 	
	x 	x
Do not want to reveal tokens for better security 	x 	
Want client authentication 	x 	
Want refresh token 	x 	
Slow front channel, fast back channel 	x 	

Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd. 
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/0c805959/attachment.html>

More information about the Openid-specs-ab mailing list