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

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Tue Jun 5 20:29:42 UTC 2012


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



More information about the Openid-specs-ab mailing list