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

[John Bradley]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120605/09064f96/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120605/09064f96/attachment.p7s>