FYI, I blogged about these changes in my post “Late-breaking changes to OAuth 
Token Exchange syntax” at http://self-issued.info/?p=1825 and at 
@selfissued<https://twitter.com/selfissued>.

                                                                -- Mike

From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell
Sent: Monday, April 23, 2018 1:45 PM
To: George Fletcher <gffle...@aol.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

draft -13 was just published with these changes

On Mon, Apr 23, 2018 at 2:15 PM, George Fletcher 
<gffle...@aol.com<mailto:gffle...@aol.com>> wrote:
+1

On 4/23/18 3:13 PM, Brian Campbell wrote:
I just noticed/remembered that the draft also currently defines a "cid" claim 
for the client identifier where Introspection's RFC 7662 already uses 
"client_id" for the same thing. The reason for using "cid" was similar in that 
I was looking to follow the semi-convention of JWT using three letter short 
claim names. But I think consistency with RFC 7662 is more important and 
meaningful here. So, barring a rough conscious of objections, I'm going to make 
that change too in a soon-to-be next revision of the draft.


On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt 
<tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote:
+1 - It will makes thinks much simpler.



Am 19.04.2018 um 00:58 schrieb Mike Jones 
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>:

I’m OK with this change, given it makes the OAuth suite of specs more 
self-consistent.

                                                       -- Mike

From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf 
Of Brian Campbell
Sent: Wednesday, April 18, 2018 8:17 AM
To: Torsten Lodderstedt 
<tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

The draft-ietf-oauth-token-exchange document makes use of scope and at some 
point in that work it came to light that, despite the concept of scope being 
used lots of places elsewhere, there was no officially registered JWT claim for 
scope. As a result, we (the WG) decided to have draft-ietf-oauth-token-exchange 
define and register a JWT claim for scope. It's kind of an awkward place for it 
really but that's how it came to be there.
When I added it to the draft, I opted for the semi-convention of JWT using 
three letter short claim names.. And decided to use a JSON array to convey 
multiple values rather than space delimiting. It seemed like a good idea at the 
time - more consistent with other JWT claim names and cleaner to use the 
facilities of JSON rather than a delimited string. That was the thinking at the 
time anyway and, as I recall, I asked the WG about doing it that way at one of 
the meetings and there was general, if somewhat absent, nodding in the room.
Looking at this again in the context of the question from Torsten and his 
developers, I think using a different name and syntax for the JWT claim vs.. 
the Introspection response member/parameter/claim is probably a mistake.  While 
RFC 7662 Introspection response parameters aren't exactly the same as JWT 
claims, they are similar in many respects. So giving consistent treatment 
across them to something like scope is
Therefore I propose that the JWT claim for representing scope in 
draft-ietf-oauth-token-exchange be changed to be consistent with the treatment 
of scope in RFC 7662 OAuth 2.0 Token Introspection. That effectively means 
changing the name from "scp" to "scope" and the value from a JSON array to a 
string delimited by spaces.
I realize it's late in the process to make this change but believe doing so 
will significantly reduce confusion and issues in the long run.





On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt 
<tors...@lodderstedt.net<mailto:tors...@lodderstedt..net>> wrote:
Hi all,

I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ to 
carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the same 
purpose. As far as I understand the text, the intension is to represent a list 
of RFC6749 scopes. Is this correct? What’s the rationale behind?

Different claim names for representing scope values confuse people. I realized 
that when one of our developers pointed out that difference recently.

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.

_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://www..ietf.org/mailman/listinfo/oauth>


--

Distinguished Engineer

Identity Services Engineering     Work: 
george.fletc...@teamaol.com<mailto:george.fletc...@teamaol.com>

AOL Inc.                          AIM:  gffletch

Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch

Office: +1-703-265-2544           Photos: http://georgefletcher.photography


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to