[Openid-specs-ab] Special spec call notes 15-Jun-12

[Vladimir Dzhuvinov / NimbusDS]

Thank you guys for settling the claims_in_id_token issue.

I have to say I thought a lot about it, also from the broader
perspective of OAuth 2.0. But couldn't see a way to encode it, apart
from the existing request object method, that would feel right and
sound. So the decision to drop it is probably the best that could be
done in this situation.

Still, I now realise it will make sense to simplify this request for
clients and I plan to add an explicit option to our SDK API to request
the claims to be packed into the ID token (and let the SDK internals
construct the appropriate request object for this).


Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
 







-------- Original Message --------
Subject: [Openid-specs-ab] Special spec call notes 15-Jun-12
From: Mike Jones <Michael.Jones at microsoft.com>
Date: Fri, June 15, 2012 6:11 pm
To: "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>

  Special spec call notes 15-Jun-12
  
 Special call about syntax for requesting claims in the ID Token
  
 Nat Sakimura
 Nov Matake
 Brian Campbell
 Justin Richer
 Amanda Anganes
 Sascha Preibisch
 Mike Jones
 Ryo Ito
 Roland Hedberg
 George Fletcher
  
 Agenda:
                Requesting claims in the ID Token
                Enabling the use of URIs as OAuth client_id values
                Call scheduling
  
 Nat prepared a document with the possible set of choices before the
call:
 https://docs.google.com/document/d/1Z2FfbvPm-N3pdrpoWsBrVATz43QbMvLs2y6tdmhUT2Q/edit?pli=1
  
 There was significant discussion of the choices, some of which is
captured below
  
 There is consensus that we need the ability to return claims in the ID
Token
  
 We already have a means of requesting claims in the ID Token via the
OpenID Request Object
                This wasn't clear to Brian, Justin, and Roland
                We probably need to add an example
  
 Brian:    He is displaying scope values to the user for approval
 Nat:       Concurred that IdPs may authorize release of claims based
upon scope values
 Brian:    Argued that the openid scope is an authorization for SSO, and
so can be approved too
 Justin:    Also said that he's displaying scope-based requests to the
user
 Mike:     The openid scope modifies the behavior of the OAuth request
as a switch
 Nat:       The claims_in_id_token scope is a pure switch
 Mike:     There is the need to authorize the release of claims not
requested by scopes
 Brian:    In some enterprise contexts, consent to release claims is
implicit
 Roland: Release of claims should require consent in SAML as well
                This was discussed in the higher ed community
  
 Justin:    Putting claims in the ID Token is an advanced use case
 Mike:     Claims in the ID Token is simpler than claims in UserInfo
endpoint - UserInfo is the advanced case
 George:               ID Tokens were designed to be small - not all
claims are needed for session management
 Mike:     Claims in ID Token may be the primary way requests are made
 Justin:    Mitre plans to use the UserInfo endpoint primarily
 Nov:      Claims in ID Token is not a major use case
 Sascha: Claims in ID Token are designed just for session state
  
 Nat:       Does returning claims in ID token warrant additional scope
values?
                Most people said "no" based on an IETF-style "hum"
  
 Therefore, we will remove the claims_in_id_token scope value
                Claims in the ID Token can still be requested using the
OpenID Request Object
  
 ====
  
 Enabling the use of URIs as OAuth client_id values:
                Mike:     Raised the issue of including colons in OAuth
client_ids
                Brian:    Agreed that colon should not be disallowed
                Justin:    Suggested that the client_id always be
encoded when using HTTP Basic
                               He said so on the OAuth list
                Others also agreed that this is important
  
 Call scheduling
                We will move the Thursday call to this time (7am
Pacific)
                This time works better for Europeans and some US East
Coast participants
 
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab