[Openid-specs-ab] Inconsistency between user_id and prn claims - notice of upcoming breaking change

Wed Dec 19 16:46:46 UTC 2012

+1 for prn in both specs

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Breno de Medeiros
Sent: Wednesday, December 19, 2012 5:19 PM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Inconsistency between user_id and prn claims - notice of upcoming breaking change

While the rename represents another breaking change to Google's early implementation and will require additional transition planning, I can't say that I am against the universal usage of 'prn'. I expect that developers and deployers will appreciate being able to expect 'prn' in all their interactions.

On Tue, Dec 18, 2012 at 11:51 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Just to remove any ambiguity, was your +1 for "prn" or "sub", Torsten?

                                -- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Torsten Lodderstedt
Sent: Tuesday, December 18, 2012 10:54 AM
To: Justin Richer
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Inconsistency between user_id and prn claims - notice of upcoming breaking change

+1

Am 18.12.2012 16:10, schrieb Justin Richer:
> +1, though I prefer "sub" over "prn" as it reads better.
>
>  -- Justin
>
> On 12/18/2012 03:37 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> +1 for prn. Consistency with OAuth JWT assertion makes good sense.
>>
>> Thanks,
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov : www.NimbusDS.com<http://www.NimbusDS.com> : vladimir at nimbusds.com<mailto:vladimir at nimbusds.com>
>>
>>
>> -------- Original Message --------
>> Subject: [Openid-specs-ab] Inconsistency between user_id and prn
>> claims
>> - notice of upcoming breaking change
>> From: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
>> Date: Tue, December 18, 2012 1:05 am
>> To: "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>"
>> <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
>> Cc: "openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>"
>> <openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>>
>>
>>    Mitre and Microsoft implementers have both recently independently
>> pointed out that an ID Token is not currently usable as an OAuth JWT
>> Assertion because it uses the "user_id" claim to identify the subject
>> of the token, rather than the "prn" (principal) claim, as specified
>> in the OAuth JWT Assertion spec.  This inconsistency is already
>> causing real problems/limitations for implementations. See
>> http://hg.openid.net/connect/issue/687 for more background on the issue.
>>      This was discussed on the working group call today and it was
>> decided that while changing the "user_id" claim name now would be
>> painful, it would be more painful over time to keep having
>> implementer's try to work around this inconsistency when they need to
>> use an ID Token as an OAuth JWT assertion.  Therefore, we decided
>> that the specs should be changed so that an ID Token is a legal OAuth
>> JWT Assertion.  The simplest way to do this would be to change all
>> uses of the claim name "user_id" to "prn".  Only the syntax would
>> change - not the meaning of the claim.
>>      The other potential solution that was discussed was to change
>> both the names "user_id" and "prn" to "sub" (subject).  While being a
>> (somewhat) more meaningful name, using "prn" was preferred because it
>> will involve a change only to the Connect specs - not also to the JWT
>> and OAuth JWT Assertion specs.
>>      The participants in the working group call decided that we
>> should make this change, but we wanted to give clear notice to the
>> working group and interop participants of this upcoming breaking
>> change.  If you would like to propose an alternative solution to the
>> inconsistency, please do so before the Thursday OpenID Connect call.
>> We plan to include this change in the upcoming implementer's drafts.
>> -- Mike
>>      _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

--
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121219/87fdfc86/attachment.html>