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

[John Bradley]

I am in favour of having JWT and id_token consistent, as long as we are not changing the semantic of user_id and only the claim name.

As I stated earlier the user_id claim was an attempt to match facebooks claims.   I don't think that logic panned out in the end.  

Better to change it once to be consistent.  For a transition period IdP could send both prn and user_id to make the change easier.  

I don't care much if the claim is called prn or sub they both are used for the same thing in other specs that couldn't agree on what to call them.

Leaving it prn is fine with me unless people overwhelmingly prefer sub.

John B.

On 2012-12-19, at 1:46 PM, <Axel.Nennker at telekom.de> wrote:

> +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> 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] On Behalf Of Torsten Lodderstedt
> Sent: Tuesday, December 18, 2012 10:54 AM
> To: Justin Richer
> 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
> 
> +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 : 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>
> >> Date: Tue, December 18, 2012 1:05 am
> >> To: "openid-specs-ab at lists.openid.net"
> >> <openid-specs-ab at lists.openid.net>
> >> Cc: "openid-connect-interop at googlegroups.com"
> >> <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
> >> 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
> >
> > _______________________________________________
> > 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
>  
> -- 
> --Breno
> 
> _______________________________________________
> 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/20121219/b9281730/attachment.html>