[Openid-specs-ab] Lite Draft 9

John Bradley ve7jtb at ve7jtb.com
Mon Aug 22 18:22:59 UTC 2011


In my discussion with Breno, his intention is that the Check Session endpoint is a OAuth protected resource.  The id_token is sent as the access token for accessing that resource, per the OAuth spec.

It is NOT a parameter for a API,  it is the access token.

Breno should correct if I have that wrong.

It makes the most sense to me to think of openID Connect returning two access tokens for two protected resources, perhaps I am simple.

John


On 2011-08-19, at 10:06 PM, Nat Sakimura wrote:

> question: 
> 
> The messages spec states: 
> 
> 3.4.1.  Check Session Request
> 
> To request the information about the authentication performed on the user, the following parameters are sent to the Check Session endpoint:
> 
> 
> id_token
> REQUIRED. The ID Token obtained from an OpenID Connect authorization request.
> 
> and the Standard spec states:
> 
> 7.1.  Client Session Requests
> 
> Clients MUST make a HTTP POST request using transport-layer security with the following application/x-www-form-urlencodedparameters in the request body:
> 
> 
> id_token
> REQUIRED. The ID Token obtained from an OpenID Connect authorization request.
> 
> The Following is a non-normative example of an Check Session request:
> 
> 
> I think these descriptions are correct from older drafts point of view. Since it is just a parameter, it can be used in conjunction with authentication. 
> 
> If it is changed to be an access token, this description is wrong needs to be updated. 
> 
> Could you kindly clarify?
> 
> =nat via iPad
> 
> On 2011/08/20, at 4:12, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 
>> The id_token is the access token for the check session endpoint.
>> 
>> Only the id_token is sent to the check session endpoint.
>> 
>> As Oauth only has one access token we have to give the access token for the session endpoints a separate name.  That is id_token.  I did rase the possibility of calling it session but no one took me up on that.
>> 
>> The access token for the check session endpoint is a signed JWT that way a client can inspect it directly and never use the check session endpoint.
>> 
>> John B.
>> On 2011-08-19, at 3:06 PM, Allen Tom wrote:
>> 
>>> In section 3.3.1 - Are both the access_token and the id_token supposed to be sent to the Check Session endpoint? The way that Section 3.3.1 in Draft 9 is currently written, it sounds like only the id_token is sent in the request, and that the id_token is actually the access_token.
>>> 
>>> It would probably be helpful to have an example Check Session request in the spec.
>>> 
>>> Allen
>>> 
>>> 
>>> On Fri, Aug 19, 2011 at 12:02 PM, Allen Tom <allentomdude at gmail.com> wrote:
>>> The explanation in Section 3 regarding when to use the Implicit vs Code flow is vague, because it's not clear as to what it means for a client to securely maintain state between itself and the auth server.
>>> 
>>> It might be better to just say that the Code flow should be used if the redirect_uri doesn't use HTTPS, and if the client is able to securely store its client_secret.
>>> 
>>> Allen
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110822/c22bef14/attachment.html>
-------------- 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/20110822/c22bef14/attachment.p7s>


More information about the Openid-specs-ab mailing list