[Openid-specs-ab] Multiple response types

[Roland Hedberg]

3 nov 2011 kl. 21:34 skrev John Bradley:

> The term implicit flow should probably be fragment encoded flow,  so yes both come back in the fragment like the implicit example in OAuth 2.0.
> 
> The only response_type that is not fragment encoded is code.

I wouldn't mind if that simple sentence was added to the text.

>> Coming back to the second part of my question: if both 'code' and 'access_token' is return together what use does the client have of 'code'.
> 
> Yes it can use it to get a refresh token, and id_token in the back channel.
> 
> The common use may be if the RP is not TLS enabled.
> 
> You may ask for 'code token' and have the JS only pass back token to the home server.  The JS can use the access token to access the protected resource over TLS.
> The Server exchanges code & client secret for id_token, access_token, and  refresh_token in the back channel.
> 
> It is a way to get tokens to both parts of the client without passing the access token over a unprotected channel.

So is this use case the reason for the multiple response types containing 'code' ?

>> It would be nice if the text elaborated a bit on how the multivalued response-types influences the flows.
> 
> I thought the new text I added cleared it up, but perhaps not enough.
> 
> Did you look at the registration spec for the return_types

Yes! didn't help.
It's one thing to know how to construct a response it's another to understand why that specific variant is defined.

-- Roland