That is what we are doing for connect. If other applications like Persona wind up using the same claims that ids fine as long as the semantics are the same. On 2013-08-01, at 1:29 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote:
> Hi Mike, > > thank you for your quick answer. Using the registry works for my use cases. > > regards, > Torsten. > > Am 01.08.2013 12:09, schrieb Mike Jones: >> If you want to propose that specific claims be added that are already >> in widespread use, I suspect that the working group might be amenable >> to that. That being said, we've tried to be conservative and only >> define claims in the JWT spec itself that there is clear prior art for >> and which are therefore known to be of widespread general >> applicability. >> Also, there's no reason for all claims to be defined in the JWT spec >> itself, since there's a JSON Web Token Claims Registry, and >> implementations are free to/expected to use claims defined in the >> registry that are not defined in the base spec. In the case of the >> "acr", "amr", and "auth_time" claims, those are already queued up to >> be added to the registry when the OpenID Connect specs complete (see >> the IANA Considerations section at >> http://openid.net/specs/openid-connect-messages-1_0.html#ClaimsRegistry), >> so there's not a compelling reason to also define them in the JWT >> spec, as they'll be available in the registry whether we add them to >> the JWT spec or not. >> -- Mike >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> Behalf Of Torsten Lodderstedt >> Sent: Thursday, August 01, 2013 2:21 AM >> To: oauth@ietf.org WG >> Subject: [OAUTH-WG] JWT/JWT Bearer Token Profile >> Hi, >> why does the JWT draft not specify any claim to represent information >> about the authentication transaction itself, such as acr, amr or >> auth_time? And in turn, JWT Bearer Token Profile also does not give >> any processing rules. In my opinion, this may require additional >> profiling of the JWT Bearer Token Profile for ID token processing, if >> the receiving AS wants to apply a policy on the authentication. >> regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
