[Openid-specs-ab] Issue #898: New Core - 1.2 Terminology - Authentication Request, Authorization Request (openid/connect)

Nat Sakimura sakimura at gmail.com
Wed Nov 6 10:22:27 UTC 2013


Right. It may be a good idea to clarify it as it is a bit obscure right now. 

Only the time that access token is not returned is when response type is id_token and in that case it is returned from the authz endpoint and not the token endpoint. 

While on the topic, I kind of feel that it may be a good idea to return iss and aud claim as well. It should not break any client and savvy client can make use of them for more protection. 

=nat via iPhone

Nov 6, 2013 1:25、"Vladimir Dzhuvinov / NimbusDS" <vladimir at nimbusds.com> のメッセージ:

> Hi guys,
> 
> My reading of the OIDC spec has been that a valid access token is always
> returned for a code grant, even if the scope is set to "openid" only. In
> that case the UserInfo endpoint will simply return the "sub" claim and
> nothing else when the access token is presented. 4.3.2.  Successful
> UserInfo Response says "The sub (subject) Claim MUST always be returned
> in the UserInfo Response."
> 
> I also remember (please correct me if I'm wrong) there being a paragraph
> in '4.1. Requesting Claims using Scope Values' saying that the openid
> scope value is REQUIRED and requests access to the 'sub' claim.
> 
> 
> Vladimir
> 
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
> 
> -------- Original Message --------
> Subject: Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology -
> Authentication Request, Authorization Request (openid/connect)
> From: Anthony Nadalin <tonynad at microsoft.com>
> Date: Tue, November 05, 2013 8:32 pm
> To: Mike Jones <Michael.Jones at microsoft.com>, Nat Sakimura
> <sakimura at gmail.com>
> Cc: "openid-specs-ab at lists.openid.net"
> <openid-specs-ab at lists.openid.net>
> 
>   I understand Torsten’s point, the meta issue is what is a token
> endpoint, as you can just return a id_token and have the access token be
> NULL and that would satisfy the specification and Torsten could not
> complain that it was a violation. Seems like the token endpoint needs to
> be sorted out 
> 
>   From: Mike Jones 
> Sent: Tuesday, November 5, 2013 12:21 PM
> To: Anthony Nadalin; Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net
> Subject: RE: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology -
> Authentication Request, Authorization Request (openid/connect)
> 
> 
> 
>   Torsten's comment about the Token Endpoint was that he believes that
> it must always return an Access Token.  He wasn't objecting to it
> returning other things like Refresh Tokens, ID Tokens, etc.
> 
> Indeed RFC 6749 includes an example of it returning a non-standard
> field.
> 
> -- Mike
> 
> 
> 
> From: Anthony Nadalin
> Sent:  ý11/ý5/ý2013 12:07 PM
> To: Mike Jones; Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net
> Subject:  RE: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology
> - Authentication Request, Authorization Request (openid/connect)
> 
> There is the issue of what an token endpoint should and should not
> return. It was clear from yesterdays Oauth discussions that people have
> different views, some people believe the openid returning an I'd token
> is not in the sprit of the Oauth specification
> 
> Sent from my Windows Phone
> 
> 
> 
> From: Mike Jones
> Sent:  ý11/ý5/ý2013 11:35 AM
> To: Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net
> Subject:  Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology
> - Authentication Request, Authorization Request (openid/connect)
> 
> The ID Token part is not part of the Authentication Request.  It’s
> contained in a response which is either an Authorization Response or
> Token Response, depending upon the flow used.  Therefore, I didn’t say
> anything about the ID Token in the Authentication Request definition.
> 
> We’re now talking about the ID Token in lots of introductory text, so
> I don’t think not saying anything about it in this definition a
> problem.
> 
>                                                             -- Mike
> 
> From: Nat Sakimura [mailto:sakimura at gmail.com] 
> Sent: Tuesday, November 05, 2013 1:36 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology -
> Authentication Request, Authorization Request (openid/connect)
> 
>  What about:
> 
> 
> **Authentication Request**
> Authorization Request used to obtain the result of authentication
> performed by the server as ID Token through the use of OpenID Connect
> extension parameters and profiled scopes
> 
> 
> 
> What is important about it is that the authentication is performed at
> the server and the result is transferred from the server to the client
> through ID Token. 
> 
> 
> 
>  2013/11/5 Mike Jones <Michael.Jones at microsoft.com>
> I'm fine with adding the "Authorization Request" definition.  As for
> the Authentication Request definition, I have some quibbles with Nat's
> proposed language, because I find it to be less clear and somewhat
> circular.  Saying "to obtain the Authentication Result" doesn't add
> anything, and in fact, would just cause us to have to define
> "Authentication Result" as well.
> 
> How about something closer to this?
> 
> **Authentication Request**
> An OAuth 2.0 Authorization Request using extension parameters and
> scopes defined by OpenID Connect to request that the End-User be
> authenticated by the Authorization Server, which is an OpenID Connect
> Provider.
> 
>                                 -- Mike
> 
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat
> Sakimura
> Sent: Monday, November 04, 2013 11:13 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Issue #898: New Core - 1.2 Terminology -
> Authentication Request, Authorization Request (openid/connect)
> 
> New issue 898: New Core - 1.2 Terminology - Authentication Request,
> Authorization Request 
> https://bitbucket.org/openid/connect/issue/898/new-core-12-terminology-authentication
> 
> Nat Sakimura:
> 
> Capturing Breno's request on Nov. 4 that says: "I think we should have
> an explicit entry to Authorization Request that says: "An OAuth2
> Authorization Request as defined in RFC 6749"
> And then "Authentication Request" --> With a language more similar to
> the one proposed by Nat in this thread."
> 
> **Currently**:
> 
> **Authentication Request**
> An OAuth 2.0 Authorization Request that requests that the End-User be
> authenticated by the Authorization Server.
> 
> **Proposed**:
> 
> **Authentication Request**
> Authorization Request used to obtain the Authentication Result through
> the use of OpenID Connect extension parameters and profiled scopes
> 
> **Authorization Request**
> OAuth 2 authorization request as defined in RFC 6749
> 
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
>  Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list