[Openid-specs-ab] May 25, 2012 OpenID Connect Update Release

nov matake nov at matake.jp
Thu Jun 7 05:40:24 UTC 2012


+1 for the new response type.

I don't want to have any undenyable scopes.
(If user denied "claims_in_id_token" scope, what happens?)

I'm OK with both making single "id_token_with_userinfo" response type or combination of "id_token" and "userinfo".

nov

On 2012/06/06, at 5:29, Vladimir Dzhuvinov / NimbusDS wrote:

> Hi guys,
> 
> I just started work on updating our OpenID Connect SDK to the latest
> revision.
> 
> From a programming perspective I regard this extended ID token in a
> class of its own. To me, the logical way to request it is by means of an
> additional response type, e.g. extended_id_token or
> id_token_with_userinfo.
> 
> My understanding of "scope" has been that it is purely a spec of which
> claims sets the client wants to receive, and not about the "how" and
> "where". And this is how we had it implemented, as a set of enum values
> that map to claim names.
> 
> 
> Vladimir
> 
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update
> Release
> From: Brian Campbell <bcampbell at pingidentity.com>
> Date: Tue, June 05, 2012 6:49 pm
> To: John Bradley <ve7jtb at ve7jtb.com>
> Cc: "openid-specs-ab at lists.openid.net"
> <openid-specs-ab at lists.openid.net>
> 
> I'm just saying that for the simple case (IMHO) it would make more sense
> and be cleaner to define a request parameter for the flag rather than a
> special scope value. The request object can stay complicated for the
> complicated and granular cases.
> 
> On Tue, Jun 5, 2012 at 11:35 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> Per Mikes note, it will take a significant consensus to change the
> decision from the in person meeting.
> 
> We currently have a way to ask for the claims as part of the id_token,
> via the request object.  That is still there,  would adding an aditional
> OAuth parameter be an improvement over the request object?
> 
> 
> The goal was having simple way to do it for basic clients.  
> 
> 
> John B.
> 
> 
> 
> On 2012-06-05, at 1:13 PM, Brian Campbell wrote:
> 
> I haven't thought though all the cases so this might be short sighted
> but it would seem that adding a new parameter to the request would be
> the way to go.  As you say, id_token is already a divergence from OAuth
> so it seems reasonable to have a divergent parameter that toggles the
> claims that go in it.
> 
> So I guess my preference would be to add a new request param (probably
> named claims_in_id_token) to the authorization request along the lines
> of what's already being done for nonce, display, prompt, etc.
> 
> 
> On Tue, Jun 5, 2012 at 10:53 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> I don't know that anyone is deeply attached to having it as a scope.  
> The idea was to not require a request object.
> 
> Scopes implicitly specify the RS endpoint.   This is sort of modifying
> the endpoint for other scopes, and I understand that is a touch awkward.
> 
> 
> Would something like having separate scopes like:
> email_id
> profile_id
> phone_id 
> address_id
> 
> 
> If you ask for email it comes back from user_info and if you ask for
> email_id it is in the id_token.
> 
> 
> Or is there something else you are thinking such as adding an extra
> parameter?  We are trying not to diverge from OAuth as much as possible.
> (Yes I know id_token is a big divergence)
> 
> 
> If people don't like the claims_in_id_token scope then lets get
> alternate proposals on the table quickly.
> 
> 
> John B.
> 
> 
> On 2012-06-05, at 12:25 PM, Brian Campbell wrote:
> 
> 
> 
> I'm trying to understand why a scope was used to indicate the desire for
> user info claims to be returned in the ID Token? It really seems like
> something that should be isolated to a flag on the request (a new
> parameter or something in the request object). It feels out of place as
> a scope and will require ASs to have special conditional treatment of
> that one scope value (which I'd like to avoid as I'd think most
> implementers would). 
> 
> 
> On Sat, May 26, 2012 at 12:13 AM, Mike Jones
> <Michael.Jones at microsoft.com> wrote:
> 
> Added scope value claims_in_id_token as a switch to indicate that the
> UserInfo claims should be returned in the ID Token, per issue #561 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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