[Openid-specs-ab] Check ID Immediate

[John Bradley]

If the request was with a response_type=code&display=none  then the error would be in the parameter. 

The requests and responses are always ion the fragment unless the response_type=code.

The wording needs some work, but I think we agree on what is going on.

John B.
On 2011-10-03, at 6:28 PM, Breno de Medeiros wrote:

> Clarification: The response would be fragment-encoded (both success
> and error responses are fragment encoded).
> 
> On Mon, Oct 3, 2011 at 14:25, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> The RP may want to silently login a returning user if they know the users IdP, or they may want to confirm that the user they have currently logged in still has an active session with their OP.
>> This is typically done through a iframe giving the OP no place to percent a dialog.
>> 
>> In openID 2.0 this was called check_id_imediate.
>> 
>> In OAuth 2.0 we can specify a response_type of id_token if we don't require an access token.
>> Using the OAuth display parameter in the existing spec the OP can be signalled not to present the user with any dialog.
>> 
>> The request would be:
>> https://server.example.com/op/authorize?
>> response_type=id_token
>> &display=none
>> &client_id=s6BhdRkqt3
>> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>> &scope=openid
>> &state=af0ifjsldkj
>> 
>> The response would be fragment encoded if positive.
>> 
>> The likely error codes are (From messages 3.1.4.1):
>> login_required:  User has no session
>> session_selection_required:  Multiple sessions at OP
>> approval_required:  User has not authorized the RP to log them in.
>> 
>> Some IdP may choose to  return login_required vs approval_required to prevent unknown RP from determining if the user has an account.
>> 
>> In the case where the user has multiple sessions at the IdP being able to send a hint from the RP would be beneficial.  In the case where you just want to check if the session for a particular user is still active.
>> The simpler way to do that would be to send the id_token in the request.
>> 
>> I think this is a better approach than having the special session management endpoint.
>> The "code", "token id_token" and "code id_token" flows work as well.  You would use those if the user doesn't already have a access token, and you need one.
>> 
>> We do currently have the id_tokens expiring.  Should a RP with an expired id_token perform the display-none flow to get a fresh id_token?
>> I suspect that IdP will set the lifetime on id_tokens to be long.  Especially if they are supporting a active SLO mechanism.
>> 
>> I don't think this requires any normative changes to the existing spec, unless we want to add the ability to send the id_token in the authorization request.
>> 
>> I do think we need to add a section explaining the display=none behaviour.
>> 
>> John B.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
> 
> 
> 
> -- 
> --Breno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111003/4c47cf2d/attachment.p7s>