Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

From: Tim Bray <[email-masked]>
Date: Wed, 5 Jun 2013 13:59:42 -0700

FWIW, I just read the spec through with fresh eyes, and I found the
explanation of the workflow in 1.4.2 very useful.

- A developer manually registers and then is able to request “Initial
tokens” tokens for a dynamic-app-registration-scope,
- you use that “Initial token” token to register, in exchange you get the
client-id & so on, and also a a per-registration “Registration token” for
updating that particular registration information
- you fetch/update/delete your registration information with that
registration token.

The first part, where the developer registers & gets a token for a scope,
is vanilla OAuth 2. (right?)  The bit about getting an access token
specific to that registration is a new flow (right?), but it seems
convenient.   From an OAuth 2 point of view, there's nothing special about
how you get or use the Initial token, but giving it a special name makes
explaining a plausible workflow easier.

Having said that, I have trouble imagining the scenario where you'd use the
1.4.1 flow, but that may be because of my Google-centric worldview.

And I’m not sure 1.4.3 adds any value at all.  It just seems to be a matter
of different ways you could get and make use of the registration access
token; and I'm sure there are various interesting combinations that haven't
been thought of there.  I'd just lose 1.4.3.

 -T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <
[email-masked]> wrote:

> See my comments inline [DFC]****
>
> ** **
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
> ** **
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
> ** **
>
> Phone:      (949) 636-8571****
>
> Email:       [email-masked]****
>
> ** **
>
> *From:* Justin Richer [mailto:[email-masked]]
> *Sent:* Friday, May 31, 2013 12:40 PM
> *To:* Phil Hunt
> *Cc:* Donald F Coffin; [email-masked]
>
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
> ** **
>
> I feel the need to clarify a couple erroneous things in Phil's statement:
>
>
>   * To be clear, Draft 11 has the same Registration Access Token system
> that has been in place since draft 01, it is not inventing something new at
> the last minute as could be inferred from the statement below.****
>
> [DFC]  I agree with Justin.  There is nothing new in draft 11 regarding
> Registration Access Tokens that wasn’t in the initial draft.  It appears
> because Phil hasn’t been following the proposed drafts until the last call
> he is now raising an issue no one in the WG saw as an issue.  That’s not to
> say his point isn’t valid, but the discussion continues to go all over the
> map between “local” and “federated” tokens, usage of the RFC6749 “Token”
> endpoint, etc.  It would be great if all of Phil’s points could be
> addressed in priority
> without the threads becoming so convoluted no one is able to make sense or
> even comprehend the point being discussed.****
>
>
>   * DynReg is using an absolutely standard OAuth 2 Bearer token as the
> Registration Access Token, it's just not coming from a Token Endpoint.
> However, since an OAuth Protected Resource doesn't care where its tokens
> come from so long as it can validate them, I don't see this as a problem --
> this is a key point where Phil and I disagree.****
>
> [DFC]  I understand the disagreement, but I have not seen a proposal from
> Phil that would describe the differences between the two perspectives other
> than to say that the Dynamic Registration should use the Token endpoint
> defined in RFC6749, which does not    discuss dynamic registration.  Phil’s
> point as I understand it is that there should be no difference between an
> access token used to access resource owner protected data and the
> registration structure, which I do not agree with.  As I said in the
> previous
>             response, my users do NOT want to provide implied access to
> resource owner protected data just because a client is creating a
> registration with an AS.  This would be the situation if the client
> credential flow is used to register an application.  Since our
>             implementation does NOT support the implicit flow, that use
> case is one we have elected NOT to support.****
>
>             [DFC]  I repeat my initial comment, this conversation has been
> a circular exchange now for the past few days without any appearance of an
> alternative option to resolve the issues.****
>
>
>  -- Justin****
>
> On 05/31/2013 03:33 PM, Phil Hunt wrote:****
>
> Don,****
>
> ** **
>
> I am not proposing any change in meaning. If registration acces token
> issues by normal token server with scope registration everything is clear
> as it is for any other protected API. Draft 11 invents a whole new system.
> I strongly disagree with this.
>
> Phil****
>
>
> On 2013-05-31, at 15:16, Donald F Coffin <[email-masked]>
> wrote:****
>
> For something that was agreed to be parked a few hours ago, there sure
> seems to still be a lot of circular discussion.  Should we ask a mediator
> to intervene?****
>
>  ****
>
> FWIW I believe that is a significantly strong reason to differentiate an
> access token that can access the registration information without having
> the ability to access protected data.  Especially given the implied
> strength of the “client credential” obtained access token.  I have found it
> extremely confusing to users when explaining the difference between an
> access token obtained thorough an authorization code flow and a client
> credential flow, simply because they are both called an “access token”.
> Changing the meaning of an access token obtained through the client
> credential flow to mean it has the ability to update a registration, when a
> user may not want it to have access to protected data will only increase
> both the complexity of the access tokens as well as make their usage harder
> to explain to non-technical individuals who have to understand the
> differences between the access tokens obtained through the various flows.*
> ***
>
>  ****
>
> Just my two cents.****
>
>  ****
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
>  ****
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
>  ****
>
> Phone:      (949) 636-8571****
>
> Email:       [email-masked]****
>
>  ****
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, May 31, 2013 11:11 AM
> *To:* Justin Richer
> *Cc:* [email-masked] WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
>  ****
>
> To be clear. ****
>
>  ****
>
> It is two separate issues. ****
>
>  ****
>
> 1. Anonymous clients can easily be handled through policy config. ****
>
>  ****
>
> 2. Support for implicit clients needs to be discussed. The current
> proposal creates large negative value for the service provider and most
> would never allow in current form. Yes it gives each execution instance a
> new id, but that isnt what sp's want. It is a huge attack and management
> headache. Eliminate or propose a different solution.
>
> Phil****
>
>
> On 2013-05-31, at 13:58, Justin Richer <[email-masked]> wrote:****
>
> I'm not willing to write out an entire class of clients from this spec,
> especially when we have stated use cases for them doing dynamic
> registration.
>
> I'm sorry, but your proposed solution will simply not work.
>
>  -- Justin****
>
> On 05/31/2013 01:56 PM, Phil Hunt wrote:****
>
> Well the only client that wouldn't have a credential is an implicit
> client. An implicit client is transient and so would never update.
>
> Besides, as i have stated, implicit clients should not use dyn reg. ****
>
>
> Phil****
>
>
> On 2013-05-31, at 13:41, Justin Richer <[email-masked]> wrote:****
>
> But the outstanding question is: how do you get the access token to access
> the created resource (IE: the Registration Access Token)? You can't use the
> client_credentials flow for a client with no credentials!
>
>  -- Justin
>
>
> ****
>
> On 05/31/2013 12:58 PM, Phil Hunt wrote:****
>
> Yes. I specified the trivial solution to anonymous clients earlier.****
>
>  ****
>
> Even simpler. You don't need an access token to create a new resource. You
> just need one to access one. That is just basic security config. ****
>
>
> Phil****
>
>
> On 2013-05-31, at 12:34, Justin Richer <[email-masked]> wrote:****
>
> I agree that we are going in circles, since I just was going to bring up
> my counter argument of "what about clients with no credentials?" again,
> which *still* isn't addressed by what you suggest doing, below. I also
> believe that getting rid of the Registration Access Token but using some
> other token method would actually make the spec larger, though I'd be glad
> to review a concrete counter-proposal if you'd like to write one. And the
> fact that OIDC is doing it this way, and considered but rejected the way
> that you're describing, should say something to the WG here about whether
> or not this is the right choice. Rough consensus and running code, after
> all.
>
> Regardless, I agree to park this issue and leave the text as is. We'll
> move to the next draft in the last call process shortly, as I have a
> handful of non-normative editorial changes that I need to make, thanks to
> feedback from a few folks.
>
> Again, thanks for your thorough review, Phil, and I look forward to future
> feedback.
>
>  -- Justin****
>
> On 05/31/2013 12:28 PM, Phil Hunt wrote:****
>
> I disagree. ****
>
>  ****
>
> There is absolutely no need for a registration access token. ****
>
>  ****
>
> Get rid of it and just use access tokens as per 6749. If you can't follow
> 6749 and need new issuing methods, what are others to say regarding
> inventing new methods?****
>
>  ****
>
> I have not heard a good reason for the special process or one good enough
> to warrant a new method for issuing an access token. Does the broader group
> realize this is what the spec says?****
>
>  ****
>
> Yes, i heard a lot saying OIDC does it this way. But that is a political
> reason, not a technical reason. Still, compatibility is always a strong
> objective.  Even so, oidc could keep using their method just fine. There is
> no obligation here to do the same. ****
>
>  ****
>
> The only reason so far was expiry of client creds. Well, why not require
> the client to update prior to expiry? It makes no sense to have another
> token with longer expiry. B'sides, even expired the client can re-register
> from scratch. ****
>
>  ****
>
> Why force the client to persist multiple tokens and creds? That is far far
> too complex. ****
>
>  ****
>
> Finally if you get rid of registration access token the spec size will
> drop roughly in half IMO. This suggests simplicity to me. ****
>
>  ****
>
> Apologies for my rant. Maybe we should park this for now. We are going in
> circles.
>
> Phil****
>
>
> On 2013-05-31, at 11:25, Justin Richer <[email-masked]> wrote:****
>
> Phil,
>
> We *can* keep it straight just fine, but I just need you to be clear about
> which part you're objecting to because the answers are different. Please
> use the terms as defined in the document so that we all know which
> component we're talking about. I'm sure you'd agree than in specification
> work such as this, precision of language and labels is key for
> communication between parties. This is precisely why there's a Terminology
> section right up front, so that when I say "Registration Access Token" you
> can know that I mean a very specific thing, and when I say "Initial
> Registration Token" I mean a very different specific thing. So I'm asking
> you, please, use the defined terms so that we can avoid this unnecessary
> confusion.
>
> But anyway, what you're talking about below, "the token the client uses to
> update is profile" *IS* the Registration Access Token. That's all that that
> token is used for. You're not asking for it to go away, you're asking for
> it to come from the Token Endpoint instead of the response from the
> Registration Endpoint. I don't see how the client *can* get it from the
> normal token process without jumping through specialized hoops to make that
> happen. I've implemented the draft the way that it is right now, both
> client and server side, and it works. Others have implemented it, too.
> We've done interop testing, and it works. This is a proven pattern and from
> where I sit there is both rough consensus and running code.
>
> I believe that I've already pointed out how the solutions you've proposed
> so far won't work in practice, for various reasons, many of which have
> already been brought up and discussed previously. If you have another way
> for the client to get its Registration Access Token, please propose it; but
> I haven't seen anything yet that will fly.
>
>  -- Justin****
>
> On 05/31/2013 11:10 AM, Phil Hunt wrote:****
>
> Justin,****
>
>  ****
>
> This is my primary objection! We can't keep it straight. Their should be
> no such thing as a registrstion access token!  Just the token the client
> obtains to update its profile through the normal token request process.
>
> Phil****
>
>
> On 2013-05-31, at 10:55, Justin Richer <[email-masked]> wrote:****
>
> Which token are you referring to here?
>
> If it's the Initial Registration Token, then you could get that through
> the normal token server no problem. (The lifecycle writeups don't call this
> out explicitly but I would be willing to do so.) Or you could get it
> elsewhere. Doesn't matter, just like it doesn't matter with any other
> OAuth2 protected resource.
>
> If it's the Registration Access Token, then having the token come from the
> token endpoint would require a lot more work and complexity on behalf of
> both of the client and server. Either you end up with public clients
> getting secrets they shouldn't need or with granting clients access to the
> client_credentials flow when they shouldn't actually have it. Plus it adds
> extra round trips which don't buy you anything.
>
>  -- Justin****
>
> On 05/31/2013 10:15 AM, Phil Hunt wrote:****
>
> The preference is to have the access token for registration issued by the
> normal token server rather then by the registration endpoint. ****
>
>  ****
>
> In the current draft it is obtained through a unique process and must
> outlive the client. ****
>
>
> Phil****
>
>
> On 2013-05-30, at 19:47, "Richer, Justin P." <[email-masked]> wrote:***
> *
>
> I don't understand any of the comments below -- it already *is* an OAuth2
> protected resource without any special handling. Your access tokens can be
> short-lived, long-lived, federated, structured, random blobs ... totally
> doesn't matter. They are access tokens being used to access a normal
> protected resource. Full stop.
>
> Anything else is out of scope. The lifecycle discussions at the beginning
> are merely examples of some ways you *could* use it and are non-normative
> and non-exhaustive.
>
> You seem to be asking for something that's already in the draft.
>
>  -- Justin****
> ------------------------------
>
> *From:* Phil Hunt [[email-masked]]
> *Sent:* Thursday, May 30, 2013 7:31 PM
> *To:* Richer, Justin P.
> *Cc:* John Bradley; [email-masked] WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
>
>
> Phil****
>
>
> On 2013-05-30, at 16:11, "Richer, Justin P." <[email-masked]> wrote:***
> *
>
> Comments inline, marked by [JR].****
> ------------------------------
>
> *From:* Phil Hunt [[email-masked]]
> *Sent:* Thursday, May 30, 2013 5:25 PM
> *To:* Richer, Justin P.
> *Cc:* John Bradley; [email-masked] WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
> See below.****
>
> Phil****
>
>  ****
>
> @independentid****
>
> www.independentid.com****
>
> [email-masked]****
>
>  ****
>
>  ****
>
>  ****
>
> On 2013-05-30, at 2:09 PM, Justin Richer wrote:****
>
>
>
>
> ****
>
> OK, I think see part of the hang up. I have not seen the scenario that you
> describe, where you trade a 3rd party token for a "local" token. I have
> seen where access tokens are federated directly at the PR. (Introspection
> lets you do some good things with that pattern.) ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Jun 2013 13:19:53 +1000

Tim Bray wrote:
> FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful.  
>
> - A developer manually registers and then is able to request “Initial tokens” tokens for a dynamic-app-registration-scope, 
> - you use that “Initial token” token to register, in exchange you get the client-id & so on, and also a a per-registration “Registration token” for updating that particular registration information
> - you fetch/update/delete your registration information with that registration token.
>
> The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?)

Wrong? This doesn't sound like it has any technical connection to OAuth 2. It is a developer browsing to a service portal; presumably logging in with a password, perhaps with a 2nd factor (no OAuth here); and manually copying a credential that can be used with the 'BEARER' HTTP Authentication mechanism. There is no app orchestrating the interaction (the developer just browsed to the portal); there is no programmatic exchange of one app credential for another at an AS token endpoint. The only technical connection to OAuth 2 is that the 'BEARER' HTTP authentication mechanism is branded "OAuth 2" for marketing(?) reasons.

--
James Manger

---

From: Tim Bray <[email-masked]>
Date: Wed, 5 Jun 2013 20:23:09 -0700

I’m really missing something.  You start out with a scope you want a token
for for, you get redirected for authentication, it comes back and you do a
code flow or a browser flow and you end up getting an access token.  Smells
like OAuth 2 to me.  -T

On Wed, Jun 5, 2013 at 8:19 PM, Manger, James H <
[email-masked]> wrote:

> > - you use that “Initial token” token to register, in exchange you get
> the client-id & so on, and also a a per-registration “Registration token”
> for updating that particular registration information
> Wrong? This doesn't sound like it has any technical connection to OAuth 2.
> It is a developer browsing to a service portal; presumably logging in with
> a password, perhaps with a 2nd factor (no OAuth here); and manually copying
> a credential that can be used with the 'BEARER' HTTP Authentication
> mechanism. There is no app orchestrating the interaction (the developer
> just browsed to the portal); there is no programmatic exchange of one app
> credential for another at an AS token endpoint. The only technical
> connection to OAuth 2 is that the 'BEARER' HTTP authentication mechanism is
> branded "OAuth 2" for marketing(?) reasons.
>
> --
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Jun 2013 13:42:54 +1000

Your “first part” where a developer gets an initial token sounds like a task a developer does using only a standard web browser, knowing their developer password. There is no OAuth here; there is no app interacting (just a human at a browser).

Perhaps I should not have jumped into this thread as I have not been delving deep into registration. I guess it is conceivable that a fancy app development suite is acting as an OAuth client: directing the developer to the AS to authorize the development suite to contact the registration “protected resource” on the developers behalf. Once authorized, the development suite collects a token from the token endpoint. That token is the “initial access token”. That would be OAuth 2 for the first part.
--
James Manger

From: Tim Bray [mailto:[email-masked]]
Sent: Thursday, 6 June 2013 1:23 PM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I’m really missing something.  You start out with a scope you want a token for for, you get redirected for authentication, it comes back and you do a code flow or a browser flow and you end up getting an access token.  Smells like OAuth 2 to me.  -T

On Wed, Jun 5, 2013 at 8:19 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Jun 2013 14:06:19 +1000

BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately extensible to support other sorts of credentials (eg MAC authentication).

Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens?

1.3. “Registration Tokens and Credentials” says:

  “The Initial Access Token … is an OAuth 2.0 Bearer Token”

  “The Registration Access Token … is an OAuth 2.0 Bearer Token”

Google’s TLS ChannelIDs [draft-balfanz-tls-channelid], for instance, would be a fantastic fit for linking the first registration request with any subsequent registration modifications. The Registration Access Token would be annoying legacy baggage in that situation.

It seems that the Registration Access Token is only ever used at a single URI: registration_client_uri. That sounds like the perfect situation to use a “capability URI”, effectively putting the token in the URI. Anyone considered doing that? It should significantly simplify the spec.

--
James Manger

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Jun 2013 06:08:08 +0000

James, this is a very good question particularly since we have a working group item in progress that provides security properties beyond bearer tokens.

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Manger, James H
Sent: Thursday, June 06, 2013 7:06 AM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

--
James Manger

---

From: Tim Bray <[email-masked]>
Date: Wed, 5 Jun 2013 23:25:22 -0700

On Wed, Jun 5, 2013 at 9:06 PM, Manger, James H <
[email-masked]> wrote:

> BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is
> deliberately extensible to support other sorts of credentials (eg MAC
> authentication).****
>
> ** **
>

Because bearer tokens have a stable RFC-numbered spec and are widely
implemented and the registration flow as documented seems like it should
work?  -T

> ****
>
> ** **
>
> 1.3. “Registration Tokens and Credentials” says:****
>
> ** **
>
>   “The Initial Access Token … is an OAuth 2.0 Bearer Token”****
>
> ** **
>
>   “The Registration Access Token … is an OAuth 2.0 Bearer Token”****
>
> ** **
>
> Google’s TLS ChannelIDs [draft-balfanz-tls-channelid], for instance, would
> be a fantastic fit for linking the first registration request with any
> subsequent registration modifications. The Registration Access Token would
> be annoying legacy baggage in that situation.****
>
> ** **
>
> ** **
>
> It seems that the Registration Access Token is only ever used at a single
> URI: registration_client_uri. That sounds like the perfect situation to use
> a “capability URI”, effectively putting the token in the URI. Anyone
> considered doing that? It should significantly simplify the spec.****
>
> ** **
>
> --****
>
> James Manger****
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Jun 2013 08:15:04 +0000

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work?  -T

That’s the answer for why there is support for bearer tokens but it is not the answer to why that’s the only supported mechanism.
If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 10:53:31 +0200

There are a couple of reasons.    

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type.   The new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration.   
I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Jun 2013 08:57:36 +0000

That's fair, John.

Having a mandatory-to-implement mechanism in place is certainly useful. Pushing stronger security mechanisms to other specifications is also fine. It would be good to re-read the document to see whether we can actually fit the currently worked on security mechanisms into the spec at a later stage or whether there are some problems with the extensibility story.

Ciao
Hannes

From: ext John Bradley [mailto:[email-masked]]
Sent: Thursday, June 06, 2013 11:54 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ext Tim Bray; Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

John B.
On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]<mailto:[email-masked]>> wrote:

That's the answer for why there is support for bearer tokens but it is not the answer to why that's the only supported mechanism.
If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 11:22:19 +0200

On the face of it I think adding proof of possession aught to be possible.   The hard part will be that those mechanisms assume a registered client.

I think the trick will be not crating a circular registration problem.    Adding the other token types to the RS will be simple in comparison.

John B.

On 2013-06-06, at 10:57 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> wrote:

> That’s fair, John.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 7 Jun 2013 00:48:53 +1000

John,

Why is the circularity of registration any different for a non-bearer scheme?

A developer browsing a service portal can grab an id & secret, just as easily as grabbing a bearer token, to configure into an app as the initial access token.
A client registration endpoint can return an id & secret, just as easily as returning a bearer token, for the client to use as the registration access token.

OAuth 2 defines a JSON format for conveying an access token [RFC6749 “OAuth 2.0” section 5.1. “Issuing an access token: Successful Response”]. That might be a better syntax for an app to expect when receiving an initial access token and a registration access token, given it needs to understand that format for “real” access tokens anyway.

> Having a mandatory-to-implement mechanism in place is certainly useful

Registration supporting the same mechanism an app will use with “real” access tokens (whatever that is for this AS) would be even more useful.

--
James Manger

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, 6 June 2013 7:22 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ext Tim Bray; Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

John B.

On 2013-06-06, at 10:57 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]<mailto:[email-masked]>> wrote:

That’s fair, John.

Ciao
Hannes

From: ext John Bradley [mailto:[email-masked]<http://ve7jtb.com>]
Sent: Thursday, June 06, 2013 11:54 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ext Tim Bray; Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 08:20:08 -0700

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software. 

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap. 

Finally never-mind bearer bias, how are  client credentials rotated interoperably if the only thing rotated is client_secret?

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 12:49:38 -0400

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:
> the client-id & so on, and also a a per-registration “Registration 
> token” for updating that particular registration information

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) 
getting a token through some other means, like browsing to a developer 
portal and getting a Bearer token. I've edited the example in 1.4.3 in 
the latest (unpublished) text so that the developer is literally doing 
OAuth2 to get the initial token. It's important to note that this could 
be any flavor of OAuth2 token, though Bearer tokens are of course the 
most common.

> The bit about getting an access token specific to that registration is 
> a new flow (right?), but it seems convenient.

Right, it's a new way to get a bearer token so that you can use it at 
the protected resource. We wanted to re-use the token endpoint for this, 
but couldn't come up with a reasonable way of doing so (as has been 
discussed on the list.

>   From an OAuth 2 point of view, there's nothing special about how you 
> get or use the Initial token, but giving it a special name makes 

Right, and I've admitted that "Initial Access Token" a crappy name, but 
I haven't heard a better suggestion yet.

>
> Having said that, I have trouble imagining the scenario where you'd 
> use the 1.4.1 flow, but that may be because of my Google-centric 
> worldview.

Could be -- but if Google wants to be an open-registration identity 
provider (like it has been with OpenID 2.0), it will need to handle this 
flow as well. This is the client acting on its own behalf, showing up 
and saying "hi, I'm a client!" and that's that. I think this is a very 
important case for interoperability of dynamic registration.

>
> And I’m not sure 1.4.3 adds any value at all.  It just seems to be a 
> matter of different ways you could get and make use of the 
> registration access token; and I'm sure there are various interesting 
> combinations that haven't been thought of there.  I'd just lose 1.4.3.
>

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current 
working text is make the initial process of getting the Initial Access 
Token different (the developer now uses OAuth2 to configure their build 
environment). The *real* important difference that's being shown here, 
though, is that the client doesn't call the registration endpoint, the 
developer (and their build environment) does. So yes, it's exactly all 
about how you get and use the registration access token. There are 
plenty of other ways to do it as well, so that's why this section was a 
non-normative set of examples. To facilitate that understanding, I've 
moved it to an appendix in the working copy of draft -12.

Thanks,
  -- Justin

>  -T
>
>
>
>
>
>
> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     See my comments inline [DFC]
>
>     Best regards,
>
>     Don
>
>     Donald F. Coffin
>
>     Founder/CTO
>
>     REMI Networks
>
>     22751 El Prado Suite 6216
>
>     Rancho Santa Margarita, CA  92688-3836
>
>     Phone: (949) 636-8571 <tel:%28949%29%20636-8571>
>
>     Email: [email-masked]
>     <mailto:[email-masked]>
>
>     *From:*Justin Richer [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Donald F Coffin; [email-masked] <mailto:[email-masked]>
>
>
>     draft-ietf-oauth-dyn-reg-11.txt
>
>       * To be clear, Draft 11 has the same Registration Access Token
>     system that has been in place since draft 01, it is not inventing
>     something new at the last minute as could be inferred from the
>     statement below.
>
>     [DFC]  I agree with Justin.  There is nothing new in draft 11
>     regarding Registration Access Tokens that wasn’t in the initial
>     draft.  It appears because Phil hasn’t been following the proposed
>     drafts until the last call he is now raising an issue no one in
>     the WG saw as an issue.  That’s not to say his point isn’t valid,
>     but the discussion continues to go all over the map between
>     “local” and “federated” tokens, usage of the RFC6749 “Token”
>     without the threads becoming so convoluted no one is able to make
>     sense or even comprehend the point being discussed.
>
>
>       * DynReg is using an absolutely standard OAuth 2 Bearer token as
>     the Registration Access Token, it's just not coming from a Token
>     Endpoint. However, since an OAuth Protected Resource doesn't care
>     where its tokens come from so long as it can validate them, I
>     don't see this as a problem -- this is a key point where Phil and
>     I disagree.
>
>     [DFC]  I understand the disagreement, but I have not seen a
>     proposal from Phil that would describe the differences between the
>     two perspectives other than to say that the Dynamic Registration
>     should use the Token endpoint defined in RFC6749, which does not
>     discuss dynamic registration.  Phil’s point as I understand it is
>     that there should be no difference between an access token used to
>     access resource owner protected data and the registration
>     structure, which I do not agree with.  As I said in the previous
>                 response, my users do NOT want to provide implied
>     access to resource owner protected data just because a client is
>     creating a registration with an AS.  This would be the situation
>     if the client credential flow is used to register an application. 
>     Since our
>                 implementation does NOT support the implicit flow,
>     that use case is one we have elected NOT to support.
>
>                 [DFC]  I repeat my initial comment, this conversation
>     has been a circular exchange now for the past few days without any
>     appearance of an alternative option to resolve the issues.
>
>
>      -- Justin
>
>     On 05/31/2013 03:33 PM, Phil Hunt wrote:
>
>         Don,
>
>         I am not proposing any change in meaning. If registration
>         acces token issues by normal token server with scope
>         registration everything is clear as it is for any other
>         protected API. Draft 11 invents a whole new system. I strongly
>         disagree with this.
>
>         Phil
>
>
>         On 2013-05-31, at 15:16, Donald F Coffin
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             For something that was agreed to be parked a few hours
>             ago, there sure seems to still be a lot of circular
>             discussion.  Should we ask a mediator to intervene?
>
>             FWIW I believe that is a significantly strong reason to
>             differentiate an access token that can access the
>             registration information without having the ability to
>             access protected data.  Especially given the implied
>             strength of the “client credential” obtained access
>             token.  I have found it extremely confusing to users when
>             explaining the difference between an access token obtained
>             thorough an authorization code flow and a client
>             credential flow, simply because they are both called an
>             “access token”.  Changing the meaning of an access token
>             obtained through the client credential flow to mean it has
>             the ability to update a registration, when a user may not
>             want it to have access to protected data will only
>             increase both the complexity of the access tokens as well
>             as make their usage harder to explain to non-technical
>             individuals who have to understand the differences between
>             the access tokens obtained through the various flows.
>
>             Just my two cents.
>
>             Best regards,
>
>             Don
>
>             Donald F. Coffin
>
>             Founder/CTO
>
>             REMI Networks
>
>             22751 El Prado Suite 6216
>
>             Rancho Santa Margarita, CA  92688-3836
>
>             Phone: (949) 636-8571 <tel:%28949%29%20636-8571>
>
>             Email: [email-masked]
>             <mailto:[email-masked]>
>
>             *From:*Phil Hunt [mailto:[email-masked]]
>             *Cc:* [email-masked] <mailto:[email-masked]> WG
>             draft-ietf-oauth-dyn-reg-11.txt
>
>             To be clear.
>
>             It is two separate issues.
>
>             1. Anonymous clients can easily be handled through policy
>             config.
>
>             2. Support for implicit clients needs to be discussed. The
>             current proposal creates large negative value for the
>             service provider and most would never allow in current
>             form. Yes it gives each execution instance a new id, but
>             that isnt what sp's want. It is a huge attack and
>             management headache. Eliminate or propose a different
>             solution.
>
>             Phil
>
>
>             On 2013-05-31, at 13:58, Justin Richer <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 I'm not willing to write out an entire class of
>                 clients from this spec, especially when we have stated
>                 use cases for them doing dynamic registration.
>
>                 On 05/31/2013 01:56 PM, Phil Hunt wrote:
>
>                     Well the only client that wouldn't have a
>                     credential is an implicit client. An implicit
>                     client is transient and so would never update.
>
>                     Besides, as i have stated, implicit clients should
>                     not use dyn reg.
>
>
>                     Phil
>
>
>                     On 2013-05-31, at 13:41, Justin Richer
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>
>                         But the outstanding question is: how do you
>                         get the access token to access the created
>                         resource (IE: the Registration Access Token)?
>                         You can't use the client_credentials flow for
>                         a client with no credentials!
>
>                          -- Justin
>
>
>                         On 05/31/2013 12:58 PM, Phil Hunt wrote:
>
>                             Yes. I specified the trivial solution to
>                             anonymous clients earlier.
>
>                             Even simpler. You don't need an access
>                             token to create a new resource. You just
>                             need one to access one. That is just basic
>                             security config.
>
>
>                             Phil
>
>
>                             On 2013-05-31, at 12:34, Justin Richer
>                             <[email-masked]
>                             <mailto:[email-masked]>> wrote:
>
>                                 I agree that we are going in circles,
>                                 since I just was going to bring up my
>                                 counter argument of "what about
>                                 clients with no credentials?" again,
>                                 believe that getting rid of the
>                                 Registration Access Token but using
>                                 some other token method would actually
>                                 make the spec larger, though I'd be
>                                 glad to review a concrete
>                                 counter-proposal if you'd like to
>                                 write one. And the fact that OIDC is
>                                 doing it this way, and considered but
>                                 rejected the way that you're
>                                 describing, should say something to
>                                 the WG here about whether or not this
>                                 is the right choice. Rough consensus
>                                 and running code, after all.
>
>                                 Regardless, I agree to park this issue
>                                 and leave the text as is. We'll move
>                                 to the next draft in the last call
>                                 process shortly, as I have a handful
>                                 of non-normative editorial changes
>                                 that I need to make, thanks to
>                                 Again, thanks for your thorough
>                                 review, Phil, and I look forward to
>                                 future feedback.
>
>                                  -- Justin
>
>                                 On 05/31/2013 12:28 PM, Phil Hunt wrote:
>
>                                     I disagree.
>
>                                     There is absolutely no need for a
>                                     registration access token.
>
>                                     Get rid of it and just use access
>                                     tokens as per 6749. If you can't
>                                     follow 6749 and need new issuing
>                                     methods, what are others to say
>                                     regarding inventing new methods?
>
>                                     I have not heard a good reason for
>                                     the special process or one good
>                                     enough to warrant a new method for
>                                     issuing an access token. Does the
>                                     broader group realize this is what
>                                     the spec says?
>
>                                     Yes, i heard a lot saying OIDC
>                                     does it this way. But that is a
>                                     political reason, not a technical
>                                     reason. Still, compatibility is
>                                     always a strong objective.  Even
>                                     so, oidc could keep using their
>                                     method just fine. There is no
>                                     obligation here to do the same.
>
>                                     The only reason so far was expiry
>                                     of client creds. Well, why not
>                                     require the client to update prior
>                                     to expiry? It makes no sense to
>                                     have another token with longer
>                                     expiry. B'sides, even expired the
>                                     client can re-register from scratch.
>
>                                     Why force the client to persist
>                                     multiple tokens and creds? That is
>                                     far far too complex.
>
>                                     Finally if you get rid of
>                                     registration access token the spec
>                                     size will drop roughly in half
>                                     IMO. This suggests simplicity to me.
>
>                                     Apologies for my rant. Maybe we
>                                     should park this for now. We are
>                                     going in circles.
>
>                                     Phil
>
>
>                                     On 2013-05-31, at 11:25, Justin
>                                     Richer <[email-masked]
>                                     <mailto:[email-masked]>> wrote:
>
>                                         Phil,
>
>                                         We *can* keep it straight just
>                                         fine, but I just need you to
>                                         be clear about which part
>                                         you're objecting to because
>                                         the answers are different.
>                                         Please use the terms as
>                                         defined in the document so
>                                         that we all know which
>                                         component we're talking about.
>                                         I'm sure you'd agree than in
>                                         specification work such as
>                                         this, precision of language
>                                         and labels is key for
>                                         communication between parties.
>                                         This is precisely why there's
>                                         a Terminology section right up
>                                         front, so that when I say
>                                         "Registration Access Token"
>                                         you can know that I mean a
>                                         very specific thing, and when
>                                         I say "Initial Registration
>                                         Token" I mean a very different
>                                         specific thing. So I'm asking
>                                         you, please, use the defined
>                                         terms so that we can avoid
>                                         this unnecessary confusion.
>
>                                         But anyway, what you're
>                                         talking about below, "the
>                                         token the client uses to
>                                         update is profile" *IS* the
>                                         Registration Access Token.
>                                         That's all that that token is
>                                         used for. You're not asking
>                                         for it to go away, you're
>                                         asking for it to come from the
>                                         Token Endpoint instead of the
>                                         response from the Registration
>                                         Endpoint. I don't see how the
>                                         client *can* get it from the
>                                         normal token process without
>                                         jumping through specialized
>                                         hoops to make that happen.
>                                         I've implemented the draft the
>                                         way that it is right now, both
>                                         client and server side, and it
>                                         works. Others have implemented
>                                         it, too. We've done interop
>                                         testing, and it works. This is
>                                         a proven pattern and from
>                                         I believe that I've already
>                                         pointed out how the solutions
>                                         you've proposed so far won't
>                                         work in practice, for various
>                                         reasons, many of which have
>                                         already been brought up and
>                                         discussed previously. If you
>                                         have another way for the
>                                         client to get its Registration
>                                         Access Token, please propose
>                                         it; but I haven't seen
>                                         anything yet that will fly.
>
>                                          -- Justin
>
>                                         On 05/31/2013 11:10 AM, Phil
>                                         Hunt wrote:
>
>                                             Justin,
>
>                                             This is my primary
>                                             objection! We can't keep
>                                             it straight. Their should
>                                             be no such thing as a
>                                             registrstion access token!
>                                              Just the token the client
>                                             obtains to update its
>                                             profile through the normal
>                                             token request process.
>
>                                             Phil
>
>
>                                             On 2013-05-31, at 10:55,
>                                             Justin Richer
>                                             <[email-masked]
>                                             <mailto:[email-masked]>> wrote:
>
>                                                 Which token are you
>                                                 referring to here?
>
>                                                 If it's the Initial
>                                                 Registration Token,
>                                                 then you could get
>                                                 that through the
>                                                 normal token server no
>                                                 problem. (The
>                                                 lifecycle writeups
>                                                 don't call this out
>                                                 explicitly but I would
>                                                 be willing to do so.)
>                                                 Or you could get it
>                                                 elsewhere. Doesn't
>                                                 matter, just like it
>                                                 doesn't matter with
>                                                 any other OAuth2
>                                                 protected resource.
>
>                                                 If it's the
>                                                 Registration Access
>                                                 Token, then having the
>                                                 token come from the
>                                                 token endpoint would
>                                                 require a lot more
>                                                 work and complexity on
>                                                 behalf of both of the
>                                                 client and server.
>                                                 Either you end up with
>                                                 public clients getting
>                                                 secrets they shouldn't
>                                                 need or with granting
>                                                 clients access to the
>                                                 client_credentials
>                                                 flow when they
>                                                 shouldn't actually
>                                                 have it. Plus it adds
>                                                 extra round trips
>                                                 which don't buy you
>                                                 anything.
>
>                                                  -- Justin
>
>                                                 On 05/31/2013 10:15
>                                                 AM, Phil Hunt wrote:
>
>                                                     The preference is
>                                                     to have the access
>                                                     token for
>                                                     registration
>                                                     issued by the
>                                                     normal token
>                                                     server rather then
>                                                     by the
>                                                     registration
>                                                     endpoint.
>
>                                                     In the current
>                                                     draft it is
>                                                     obtained through a
>                                                     unique process and
>                                                     must outlive the
>                                                     client.
>
>
>                                                     Phil
>
>
>                                                     On 2013-05-30, at
>                                                     19:47, "Richer,
>                                                     Justin P."
>                                                     <[email-masked]
>                                                     <mailto:[email-masked]>>
>                                                     wrote:
>
>                                                         I don't
>                                                         understand any
>                                                         of the
>                                                         comments below
>                                                         -- it already
>                                                         *is* an OAuth2
>                                                         protected
>                                                         resource
>                                                         without any
>                                                         special
>                                                         handling. Your
>                                                         access tokens
>                                                         can be
>                                                         short-lived,
>                                                         long-lived,
>                                                         federated,
>                                                         structured,
>                                                         random blobs
>                                                         ... totally
>                                                         doesn't
>                                                         matter. They
>                                                         are access
>                                                         tokens being
>                                                         used to access
>                                                         a normal
>                                                         protected
>                                                         resource. Full
>                                                         stop.
>
>                                                         Anything else
>                                                         is out of
>                                                         scope. The
>                                                         lifecycle
>                                                         discussions at
>                                                         the beginning
>                                                         are merely
>                                                         examples of
>                                                         some ways you
>                                                         *could* use it
>                                                         and are
>                                                         non-normative
>                                                         and
>                                                         non-exhaustive.
>
>                                                         You seem to be
>                                                         asking for
>                                                         something
>                                                         that's already
>                                                         in the draft.
>
>                                                          -- Justin
>
>                                                         ------------------------------------------------------------------------
>
>                                                         *From:*Phil
>                                                         Hunt
>                                                         [[email-masked]
>                                                         <mailto:[email-masked]>]
>                                                         *Sent:*
>                                                         Thursday, May
>                                                         30, 2013 7:31 PM
>                                                         *To:* Richer,
>                                                         Justin P.
>                                                         *Cc:* John
>                                                         Bradley;
>                                                         [email-masked]
>                                                         <mailto:[email-masked]>
>                                                         WG
>                                                         *Subject:* Re:
>                                                         [OAUTH-WG]
>                                                         review
>                                                         comments on
>                                                         draft-ietf-oauth-dyn-reg-11.txt
>
>
>
>                                                         Phil
>
>
>                                                         On 2013-05-30,
>                                                         at 16:11,
>                                                         "Richer,
>                                                         Justin P."
>                                                         <[email-masked]
>                                                         <mailto:[email-masked]>>
>                                                         wrote:
>
>                                                             Comments
>                                                             inline,
>                                                             marked by
>                                                             [JR].
>
>                                                             ------------------------------------------------------------------------
>
>                                                             *From:*Phil Hunt
>                                                             [[email-masked]
>                                                             <mailto:[email-masked]>]
>                                                             *Sent:*
>                                                             Thursday,
>                                                             May 30,
>                                                             2013 5:25 PM
>                                                             *To:*
>                                                             Richer,
>                                                             Justin P.
>                                                             *Cc:* John
>                                                             Bradley;
>                                                             [email-masked]
>                                                             <mailto:[email-masked]>
>                                                             WG
>                                                             *Subject:*
>                                                             Re:
>                                                             [OAUTH-WG]
>                                                             review
>                                                             comments
>                                                             on
>                                                             draft-ietf-oauth-dyn-reg-11.txt
>
>                                                             See below.
>
>                                                             Phil
>
>                                                             @independentid
>
>                                                             www.independentid.com
>                                                             <http://www.independentid.com>
>
>                                                             [email-masked]
>                                                             <mailto:[email-masked]>
>
>                                                             On
>                                                             2013-05-30, at
>                                                             2:09 PM,
>                                                             Justin
>                                                             Richer wrote:
>
>
>
>
>                                                             OK, I
>                                                             think see
>                                                             part of
>                                                             the hang
>                                                             up. I have
>                                                             not seen
>                                                             the
>                                                             scenario
>                                                             that you
>                                                             describe,
>                                                             where you
>                                                             trade a
>                                                             3rd party
>                                                             token for
>                                                             a "local"
>                                                             token. I
>                                                             have seen
>                                                             where
>                                                             access
>                                                             tokens are
>                                                             federated
>                                                             directly
>                                                             at the PR.
>                                                             (Introspection
>                                                             lets you
>                                                             do some
>                                                             good
>                                                             things
>                                                             with that
>                                                             pattern.)
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 18:53:26 +0200

We haven't defined the various proof of possession tokens yet.  It may be that there are different registration requirements for clients being issued those tokens.

It is possible that the client must have registered and pushed a public key to the AS before it is issued a HoK token.

It may be just fine, but I can't certain of that until we define the other token types.  

What we do know is that what is proposed is in production across multiple providers, and we are gaining experience with it on some of the things that didn't work like using the client's token endpoint credential for updating the registration information.

Extensibility is good but the new token types will have there own issues that will need to be addressed in a profile.
It is not enough to say any OAuth token type can be used without a profile, because people will come back and say how is that interoperable?

Especially if we are issuing HoK tokens to clients we will likely want a way to register the public key of the client.  We don't have that yet as there is no asymmetric HoK token yet.
Once there is then we do an extension of registration to cover it.

We have people going into production soon so we can't wait for every possible token type to be defined.

John B.

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 12:56:02 -0400

James, thanks for the review.

On 06/06/2013 12:06 AM, Manger, James H wrote:
> authentication).
> 1.3. "Registration Tokens and Credentials" says:
>
> "The Initial Access Token ... is an OAuth 2.0 Bearer Token"
>

That should probably say OAuth 2.0 Token there -- I see no reason to 
constrain the Initial Access Token to be a Bearer.

> "The Registration Access Token ... is an OAuth 2.0 Bearer Token"
>

This, however, makes sense -- it's a shared secret between the server 
and the client for use with registration. Do we have a mechanism for 
passing dynamically allocated shared secrets around on HTTP calls? Yes: 
Bearer tokens.

> Google's TLS ChannelIDs [draft-balfanz-tls-channelid], for instance, 
> would be a fantastic fit for linking the first registration request 
> with any subsequent registration modifications. The Registration 
> Access Token would be annoying legacy baggage in that situation.
>

Wouldn't all OAuth tokens be "annoying legacy baggage" then?

> It seems that the Registration Access Token is only ever used at a 
> single URI: registration_client_uri. That sounds like the perfect 
> situation to use a "capability URI", effectively putting the token in 
> the URI. Anyone considered doing that? It should significantly 
> simplify the spec.
>

That would require servers to be able to differentiate clients based on 
the URI, and we got feedback from people that wanted to have the Client 
Configuration Endpoint served on a single URI so that the server 
wouldn't have to track and map different clients to different URI (see 
Tim's recent comments even). Separating the URI from the Authorization 
like this, using existing mechanisms, makes that possible.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:05:17 -0400

On 06/06/2013 11:20 AM, Phil Hunt wrote:
> As I've said before the initial auth token should nothing to do with 
> auth. It is simply an assertion given to the developer to distribute 
> in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true 
at all. It's a token that gives authorization to the registration 
endpoint. The fact that you can use it as an assertion to pass along 
signed claims is an artifact of it being an OAuth token and an OAuth 
token is an opaque string. Please read through the dynamic registration 
draft again -- it says absolutely nothing about assertions, signatures, 
or claims with regard to this token.

>
> Bearer or not bearer is a distraction. The fact that the contents and 
> format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to 
carry this kind of information is out of scope for the basic 
registration spec. I completely agree that there's value in defining 
this stuff, but as a separate and complementary spec from registration.

>
> Finally never-mind bearer bias, how are  client credentials rotated 
> interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token 
and any extension parameters, can be rotated on any call to the Read or 
Update methods (except for client_id). So if you've got another 
mechanism for doing client authentication, you can rotate that, too.

> domain where there is no interop.

Considering I've personally used it across domains and without client 
secrets (using jwks_uri to register public keys), I have to empirically 
disagree with that statement.

  -- Justin

>
> Phil
>
> On 2013-06-06, at 1:53, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> One criticism Hannes and others make of OAuth specs is they are not 
>> tightly profiled enough to be interoperable without further out of 
>> band configuration and profiling.
>>
>> I am not opposed to having this extended at some point in the future, 
>> once we have a second token type.   The new token type should be 
>> available to do updates as well.
>>
>> The problem is that starting down the HoK route potentially requires 
>> a registered client that may need to be registered to do the 
>> registration.
>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> implemented and the registration flow as documented seems like it 
>>> should work?  -T
>>> That's the answer for why there is support for bearer tokens but it 
>>> is not the answer to why that's the only supported mechanism.
>>> If we want to support stronger security mechanisms (which the group 
>>> has decided to work on already) then we need to have a story on how 
>>> to support the other mechanisms as well .

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:12:19 -0400

On 06/06/2013 10:48 AM, Manger, James H wrote:
> A developer browsing a service portal can grab an id & secret, just as 
> easily as grabbing a bearer token, to configure into an app as the 
> initial access token.
>

That's true -- and in that case, they're not doing dynamic registration 
and this spec doesn't apply. They're doing static registration, which is 
still of course an option.

But there are cases where you want to pre-authorize a developer or tie 
together a set of clients, and the Initial Access Token gives you a 
mechanism for starting that work. (Though, importantly, it doesn't 
specify everything that you'd need in order to do that.)

> A client registration endpoint can return an id & secret, just as 
> easily as returning a bearer token, for the client to use as the 

It does, for clients that use them. But not all clients use 
client_secret, and forcing all clients to have a client_secret just to 
talk to the registration endpoint doesn't fly. OpenID Connect already 
tried that approach, and failed, and we need to learn from that mistake 
instead of repeating it. What's tricky about this is that it seems like 
a perfectly reasonable thing to do on the surface but it falls apart 
quickly in implementation.

> OAuth 2 defines a JSON format for conveying an access token [RFC6749 
> "OAuth 2.0" section 5.1. "Issuing an access token: Successful 
> Response"]. That might be a better syntax for an app to expect when 
> receiving an initial access token and a registration access token, 
> given it needs to understand that format for "real" access tokens anyway.
>

How you get the initial access token is out of scope. You *can* do a 
plain old OAuth 2.0 flow and get the Initial Access Token back from the 
Token Endpoint with the syntax mentioned here. We didn't adopt that 
syntax for the registration endpoint's Registration Access Token 
response because it was argued that as a simple bearer token with no 
explicit scopes or other properties, a simple string would be 
preferable. While I would personally prefer to use the structure from 
the Token Endpoint, the Working Group decided (and convinced me) that 
locking it down to a simple bearer token in this case (just the 
Registration Access Token) is simpler for clients and servers to deal with.

> Registration supporting the same mechanism an app will use with "real" 
> access tokens (whatever that is for this AS) would be even more useful.
>

But what if the app doesn't authenticate to the token endpoint at all? 
We can't just throw out an entire class of clients.

  -- Justin

> --
>
> James Manger
>
> *From:*John Bradley [mailto:[email-masked]]
> *Sent:* Thursday, 6 June 2013 7:22 PM
> *To:* Tschofenig, Hannes (NSN - FI/Espoo)
> *Cc:* ext Tim Bray; Manger, James H; [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
>
> On the face of it I think adding proof of possession aught to be 
> possible.   The hard part will be that those mechanisms assume a 
> registered client.
>
> I think the trick will be not crating a circular registration problem. 
>    Adding the other token types to the RS will be simple in comparison.
>
> John B.
>
> On 2013-06-06, at 10:57 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" 
> Having a mandatory-to-implement mechanism in place is certainly 
> useful. Pushing stronger security mechanisms to other specifications 
> is also fine. It would be good to re-read the document to see whether 
> we can actually fit the currently worked on security mechanisms into 
> the spec at a later stage or whether there are some problems with the 
> extensibility story.
>
> Ciao
>
> Hannes
>
> *From:*ext John Bradley [mailto:[email-masked] <http://ve7jtb.com>]
> *Sent:*Thursday, June 06, 2013 11:54 AM
> *To:*Tschofenig, Hannes (NSN - FI/Espoo)
> *Cc:*ext Tim Bray; Manger, James H; [email-masked] <mailto:[email-masked]>
> *Subject:*Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
>
> The problem is that starting down the HoK route potentially requires a 
> registered client that may need to be registered to do the registration.
>
> That's the answer for why there is support for bearer tokens but it is 
> not the answer to why that's the only supported mechanism.
>
> has decided to work on already) then we need to have a story on how to 
> support the other mechanisms as well .
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:17:40 -0700

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 9:49 AM, Justin Richer wrote:

> Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most common.
> 
>> The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient.
> 
> Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on this.

*Use the normal token issuing process.*  One reason given was what about anonymous clients?  The answer is, they don't have to do anything. Remember that you have defined TWO endpoints.  The "registration endpoint" and the "configuration endpoint".  A server accepting anonymous registration simply accepts anonymous access at the "registration endpoint".  Clients wanting to update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration endpoint".

As soon as you do this, other things simplify.

1.  No need to keep "registration access token" around indefinitely. It's just an access token.  In fact it is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential rotation.
2.  No need to have a special token issuing method. Creating a new issuing process suggests that the WG can't drink its own koolaid.  Because at the first seeming challenge, the WG create a new flow. How do we expect implementers to behave?
3.  The registration/configuration API is JUST a normal OAuth2 protected API.

If the draft drops "registration access tokens", a lot of the text in the draft disappears.  The whole spec is much simpler.

> 
>>   From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.  
> 
> Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet. 
> 
>> 
>> Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview. 
> 
> Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic registration.
> 
>> 
>> And I’m not sure 1.4.3 adds any value at all.  It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there.  I'd just lose 1.4.3.
>> 
> 
> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.
> 
> Thanks,
>  -- Justin
> 
>>  -T
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <[email-masked]> wrote:
>> Phone:      (949) 636-8571
>> From: Justin Richer [mailto:[email-masked]] 
>> Sent: Friday, May 31, 2013 12:40 PM
>> To: Phil Hunt
>> Cc: Donald F Coffin; [email-masked]
>> 
>> 
>>   * To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.
>> [DFC]  I agree with Justin.  There is nothing new in draft 11 regarding Registration Access Tokens that wasn’t in the initial draft.  It appears because Phil hasn’t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an issue.  That’s not to say his point isn’t valid, but the discussion continues to go all over the map between “local” and “federated” tokens, usage of the RFC6749 “Token” endpoint, etc.  It would be great if all of Phil’s points could be addressed in priority
>> without the threads becoming so convoluted no one is able to make sense or even comprehend the point being discussed.
>> 
>> 
>>   * DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.
>> 
>> [DFC]  I understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does not    discuss dynamic registration.  Phil’s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree with.  As I said in the previous
>>             response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS.  This would be the situation if the client credential flow is used to register an application.  Since our
>>             implementation does NOT support the implicit flow, that use case is one we have elected NOT to support.
>> 
>>             [DFC]  I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.
>> 
>> 
>>  -- Justin
>> 
>> I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 15:16, Donald F Coffin <[email-masked]> wrote:
>> 
>> For something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular discussion.  Should we ask a mediator to intervene?
>> 
>>  
>> FWIW I believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data.  Especially given the implied strength of the “client credential” obtained access token.  I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an “access token”.  Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various flows.
>> 
>>  
>> Just my two cents.
>> 
>>  
>> Best regards,
>> 
>> Don
>> 
>> Donald F. Coffin
>> 
>> Founder/CTO
>> 
>>  
>> REMI Networks
>> 
>> Phone:      (949) 636-8571
>> From: Phil Hunt [mailto:[email-masked]] 
>> Sent: Friday, May 31, 2013 11:11 AM
>> To: Justin Richer
>> Cc: [email-masked] WG
>> 1. Anonymous clients can easily be handled through policy config. 
>> 
>>  
>> 2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution. 
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 13:58, Justin Richer <[email-masked]> wrote:
>> 
>> I'm not willing to write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic registration.
>> 
>> Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update. 
>> 
>> Besides, as i have stated, implicit clients should not use dyn reg. 
>> 
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 13:41, Justin Richer <[email-masked]> wrote:
>> 
>> But the outstanding question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the client_credentials flow for a client with no credentials!
>> 
>>  -- Justin
>> 
>> 
>> Yes. I specified the trivial solution to anonymous clients earlier.
>> 
>>  
>> Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config. 
>> 
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 12:34, Justin Richer <[email-masked]> wrote:
>> 
>> I agree that we are going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.
>> 
>> Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few folks.
>> 
>> Again, thanks for your thorough review, Phil, and I look forward to future feedback.
>> 
>>  -- Justin
>> 
>> There is absolutely no need                                                 for a registration access token. 
>> 
>>  
>> Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?
>> 
>>  
>> I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?
>> 
>>  
>> Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective.  Even so, oidc could keep using their method just fine. There is no obligation here to do the same. 
>> 
>>  
>> The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from scratch. 
>> 
>>  
>> Why force the client to persist multiple tokens and creds? That is far far too complex. 
>> 
>>  
>> Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me. 
>> 
>>  
>> Apologies for my rant. Maybe we should park this for now. We are going in circles. 
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 11:25, Justin Richer <[email-masked]> wrote:
>> 
>> Phil,
>> 
>> We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid                                                   this unnecessary confusion.
>> 
>> But anyway, what you're talking about                                                   below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used                                                   for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop                                                   testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running code.
>> 
>> I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been                                                   brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will fly.
>> 
>>  -- Justin
>> 
>> On 05/31/2013 11:10 AM, Phil Hunt wrote:
>> 
>> Justin,
>> 
>>  
>> This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! Just the token the client obtains to update its profile through the normal token request process.
>> 
>> Phil
>> 
>> 
>> On 2013-05-31, at 10:55, Justin Richer <[email-masked]> wrote:
>> 
>> If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.
>> 
>> If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.
>> 
>>  -- Justin
>> 
>> On 05/31/2013 10:15 AM, Phil Hunt wrote:
>> 
>> The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint.
>> 
>>  
>> In the current draft it is obtained through a unique process and must outlive the client.
>> 
>> 
>> Phil
>> 
>> 
>> On 2013-05-30, at 19:47, "Richer, Justin P." <[email-masked]> wrote:
>> 
>> I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.
>> 
>> Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.
>> 
>> From: Phil Hunt [[email-masked]]
>> Sent: Thursday, May 30, 2013 7:31 PM
>> To: Richer, Justin P.
>> Cc: John Bradley; [email-masked] WG
>> On 2013-05-30, at 16:11, "Richer, Justin P." <[email-masked]> wrote:
>> 
>> Comments inline, marked by [JR].
>> 
>> From: Phil Hunt [[email-masked]]
>> Sent: Thursday, May 30, 2013 5:25 PM
>> To: Richer, Justin P.
>> Cc: John Bradley; [email-masked] WG
>> On 2013-05-30, at 2:09 PM, Justin Richer wrote:
>> 
>> 
>> 
>> 
>> OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)
>> 
>>  
>>  
>>  
>>  
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:28:52 -0400

I feel we're still just going in circles with these arguments, but my 
comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>>> - A developer manually registers and then is able to request 
>>> “Initial tokens” tokens for a dynamic-app-registration-scope,
>>> - you use that “Initial token” token to register, in exchange you 
>>> get the client-id & so on, and also a a per-registration 
>>> “Registration token” for updating that particular registration 
>>> information
>> getting a token through some other means, like browsing to a 
>> developer portal and getting a Bearer token. I've edited the example 
>> in 1.4.3 in the latest (unpublished) text so that the developer is 
>> literally doing OAuth2 to get the initial token. It's important to 
>> note that this could be any flavor of OAuth2 token, though Bearer 
>> tokens are of course the most common.
>>
>>> The bit about getting an access token specific to that registration 
>>> is a new flow (right?), but it seems convenient.
>>
>> the protected resource. We wanted to re-use the token endpoint for 
>> this, but couldn't come up with a reasonable way of doing so (as has 
>> been discussed on the list.
>
> *Use the normal token issuing process.*  One reason given was what 
> about anonymous clients?  The answer is, they don't have to do 
> anything. Remember that you have defined TWO endpoints.  The 
> "registration endpoint" and the "configuration endpoint".  A server 
> accepting anonymous registration simply accepts anonymous access at 
> the "registration endpoint".  Clients wanting to update their profiles 
> do the normal client token request flow to the token endpoint to 
> obtain a normal access token useable at the "configuration endpoint".
>

[JR] But then you're opening up the client_credentials flow to anonymous 
clients, or you've got to be able to lock down client_credentials as a 
flow to only a special (service-specific) scope for client configuration 
purposes. This, I think, is much more complicated to implement and much 
more error prone. I don't think it's even possible in the software stack 
we're building on top of. And furthermore, you're not letting public 
clients dynamically register anymore, since you'd be forcing everyone to 
have a client secret. Your dynamic public clients would have to save the 
client secret but know to only use it at the registration endpoint, and 
not the token endpoint where they're used to. This way, it's clear. You 
get a token that you use at a given endpoint, the end.

> 1.  No need to keep "registration access token" around indefinitely. 
> It's just an access token.  In fact it is only needed for minutes 
> since it will likely only be used to read or update profiles or to 
> perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want 
to, or have them expire, if you want to limit the lifespan of your 
clients. It's only the security considerations section that suggests 
against expiring the tokens, and for good reason. But it's your choice 
to change that if you don't want longstanding read/edit access to a 
client's configuration.

> 2.  No need to have a special token issuing method. Creating a new 
> issuing process suggests that the WG can't drink its own koolaid. 
>  Because at the first seeming challenge, the WG create a new flow. How 
> do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch 
your analogy. Bearer tokens were, which is also the group's koolaid. We 
tried to go down the road you suggest and it was a dead end. Why do you 
think it will work better this time? And I'd like to point out a 
decision from several years ago now to separate the notion of "how you 
get a token" from "how you use a token" in OAuth2. OAuth1 had all of 
these rolled in together, and deployment experience showed us that 
people didn't really want to use it that way. People want components 
that make sense on their own that let you build systems like this that 
also make sense.

Forced uniformity isn't necessarily a good thing.

> 3.  The registration/configuration API is JUST a normal OAuth2 

[JR] It already is. Protected resources don't care where you get your 
tokens from, just that you have them, so from that perspective it is 
just a protected resource. Our implementation here literally just looks 
for the token on the way in in the auth layer and makes sure it's got a 
special service-specific scope that handles registration.

>
> If the draft drops "registration access tokens", a lot of the text in 
> the draft disappears.  The whole spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And 
honestly, not much of the text actually goes away. Most of the draft 
isn't about dealing with the registration access token, it's about 
dealing with the client metadata and the RESTful protocol for managing 
that. The registration access token is a mechanism for doing so.

>
>>
>>>   From an OAuth 2 point of view, there's nothing special about how 
>>> you get or use the Initial token, but giving it a special name makes 
>> Right, and I've admitted that "Initial Access Token" a crappy name, 
>> but I haven't heard a better suggestion yet.
>>
>>>
>> provider (like it has been with OpenID 2.0), it will need to handle 
>> this flow as well. This is the client acting on its own behalf, 
>> showing up and saying "hi, I'm a client!" and that's that. I think 
>> this is a very important case for interoperability of dynamic 
>> registration.
>>
>>>
>>> registration access token; and I'm sure there are various 
>>> interesting combinations that haven't been thought of there.  I'd 
>>> just lose 1.4.3.
>>>
>>
>> working text is make the initial process of getting the Initial 
>> Access Token different (the developer now uses OAuth2 to configure 
>> their build environment). The *real* important difference that's 
>> being shown here, though, is that the client doesn't call the 
>> registration endpoint, the developer (and their build environment) 
>> does. So yes, it's exactly all about how you get and use the 
>> registration access token. There are plenty of other ways to do it as 
>> well, so that's why this section was a non-normative set of examples. 
>> To facilitate that understanding, I've moved it to an appendix in the 
>> working copy of draft -12.
>>
>> Thanks,
>>  -- Justin
>>
>>>  -T
>>>
>>>
>>>
>>>
>>>
>>>
>>>     system that has been in place since draft 01, it is not
>>>     inventing something new at the last minute as could be inferred
>>>     from the statement below.
>>>
>>>     draft.  It appears because Phil hasn’t been following the
>>>     proposed drafts until the last call he is now raising an issue
>>>     no one in the WG saw as an issue.  That’s not to say his point
>>>     isn’t valid, but the discussion continues to go all over the map
>>>     between “local” and “federated” tokens, usage of the RFC6749
>>>     “Token” endpoint, etc.  It would be great if all of Phil’s
>>>     points could be addressed in priority
>>>     without the threads becoming so convoluted no one is able to
>>>     make sense or even comprehend the point being discussed.
>>>
>>>
>>>       * DynReg is using an absolutely standard OAuth 2 Bearer token
>>>     as the Registration Access Token, it's just not coming from a
>>>     Token Endpoint. However, since an OAuth Protected Resource
>>>     doesn't care where its tokens come from so long as it can
>>>     validate them, I don't see this as a problem -- this is a key
>>>     point where Phil and I disagree.
>>>
>>>     proposal from Phil that would describe the differences between
>>>     the two perspectives other than to say that the Dynamic
>>>     Registration should use the Token endpoint defined in RFC6749,
>>>     which does not    discuss dynamic registration.  Phil’s point as
>>>     I understand it is that there should be no difference between an
>>>     access token used to access resource owner protected data and
>>>     the registration structure, which I do not agree with.  As I
>>>     said in the previous
>>>     if the client credential flow is used to register an
>>>     application.  Since our
>>>     has been a circular exchange now for the past few days without
>>>     any appearance of an alternative option to resolve the issues.
>>>
>>>
>>>      -- Justin
>>>
>>>         protected API. Draft 11 invents a whole new system. I
>>>         strongly disagree with this.
>>>
>>>         Phil
>>>
>>>
>>>             token.  I have found it extremely confusing to users
>>>             when explaining the difference between an access token
>>>             obtained thorough an authorization code flow and a
>>>             client credential flow, simply because they are both
>>>             called an “access token”.  Changing the meaning of an
>>>             access token obtained through the client credential flow
>>>             to mean it has the ability to update a registration,
>>>             when a user may not want it to have access to protected
>>>             data will only increase both the complexity of the
>>>             access tokens as well as make their usage harder to
>>>             explain to non-technical individuals who have to
>>>             understand the differences between the access tokens
>>>             obtained through the various flows.
>>>
>>>
>>>             Just my two cents.
>>>
>>>
>>>             Best regards,
>>>
>>>             Don
>>>
>>>             Donald F. Coffin
>>>
>>>             Founder/CTO
>>>
>>>
>>>             REMI Networks
>>>
>>>             2. Support for implicit clients needs to be discussed.
>>>             The current proposal creates large negative value for
>>>             the service provider and most would never allow in
>>>             current form. Yes it gives each execution instance a new
>>>             id, but that isnt what sp's want. It is a huge attack
>>>             and management headache. Eliminate or propose a
>>>             different solution.
>>>
>>>             Phil
>>>
>>>
>>>             On 2013-05-31, at 13:58, Justin Richer
>>>                 clients from this spec, especially when we have
>>>                 stated use cases for them doing dynamic registration.
>>>
>>>                         resource (IE: the Registration Access
>>>                         Token)? You can't use the client_credentials
>>>                         flow for a client with no credentials!
>>>
>>>                          -- Justin
>>>
>>>
>>>                             need one to access one. That is just
>>>                             basic security config.
>>>
>>>
>>>                             Phil
>>>
>>>
>>>                                 I agree that we are going in
>>>                                 circles, since I just was going to
>>>                                 bring up my counter argument of
>>>                                 "what about clients with no
>>>                                 credentials?" again, which *still*
>>>                                 isn't addressed by what you suggest
>>>                                 doing, below. I also believe that
>>>                                 getting rid of the Registration
>>>                                 Access Token but using some other
>>>                                 token method would actually make the
>>>                                 spec larger, though I'd be glad to
>>>                                 review a concrete counter-proposal
>>>                                 if you'd like to write one. And the
>>>                                 that you're describing, should say
>>>                                 something to the WG here about
>>>                                 whether or not this is the right
>>>                                 choice. Rough consensus and running
>>>                                 code, after all.
>>>
>>>                                 Regardless, I agree to park this
>>>                                 issue and leave the text as is.
>>>                                 We'll move to the next draft in the
>>>                                 last call process shortly, as I have
>>>                                 a handful of non-normative editorial
>>>                                 changes that I need to make, thanks
>>>                                 to feedback from a few folks.
>>>
>>>                                     Get rid of it and just use
>>>                                     access tokens as per 6749. If
>>>                                     you can't follow 6749 and need
>>>                                     new issuing methods, what are
>>>                                     others to say regarding
>>>                                     inventing new methods?
>>>
>>>
>>>                                     I have not heard a good reason
>>>                                     for the special process or one
>>>                                     good enough to warrant a new
>>>                                     method for issuing an access
>>>                                     token. Does the broader group
>>>                                     realize this is what the spec says?
>>>
>>>
>>>                                     political reason, not a
>>>                                     technical reason. Still,
>>>                                     compatibility is always a strong
>>>                                     objective.  Even so, oidc could
>>>                                     keep using their method just
>>>                                     fine. There is no obligation
>>>                                     here to do the same.
>>>
>>>
>>>                                     The only reason so far was
>>>                                     expiry of client creds. Well,
>>>                                     why not require the client to
>>>                                     update prior to expiry? It makes
>>>                                     no sense to have another token
>>>                                     with longer expiry. B'sides,
>>>                                     even expired the client can
>>>                                     re-register from scratch.
>>>
>>>
>>>                                     multiple tokens and creds? That
>>>                                     is far far too complex.
>>>
>>>
>>>                                     registration access token the
>>>                                     spec size will drop roughly in
>>>                                     half IMO. This suggests
>>>                                     simplicity to me.
>>>
>>>
>>>                                         We *can* keep it straight
>>>                                         just fine, but I just need
>>>                                         you to be clear about which
>>>                                         part you're objecting to
>>>                                         because the answers are
>>>                                         different. Please use the
>>>                                         terms as defined in the
>>>                                         document so that we all know
>>>                                         which component we're
>>>                                         talking about. I'm sure
>>>                                         you'd agree than in
>>>                                         communication between
>>>                                         parties. This is precisely
>>>                                         why there's a Terminology
>>>                                         section right up front, so
>>>                                         that when I say
>>>                                         very specific thing, and
>>>                                         when I say "Initial
>>>                                         Registration Token" I mean a
>>>                                         very different specific
>>>                                         thing. So I'm asking you,
>>>                                         please, use the defined
>>>                                         That's all that that token
>>>                                         is used for. You're not
>>>                                         asking for it to go away,
>>>                                         you're asking for it to come
>>>                                         from the Token Endpoint
>>>                                         instead of the response from
>>>                                         the Registration Endpoint. I
>>>                                         don't see how the client
>>>                                         *can* get it from the normal
>>>                                         token process without
>>>                                         I've implemented the draft
>>>                                         the way that it is right
>>>                                         now, both client and server
>>>                                         side, and it works. Others
>>>                                         have implemented it, too.
>>>                                         We've done interop testing,
>>>                                         and it works. This is a
>>>                                         proven pattern and from
>>>                                         where I sit there is both
>>>                                         rough consensus and running
>>>                                         code.
>>>
>>>                                         pointed out how the
>>>                                         solutions you've proposed so
>>>                                         far won't work in practice,
>>>                                         for various reasons, many of
>>>                                         which have already been
>>>                                         brought up and discussed
>>>                                         previously. If you have
>>>                                         another way for the client
>>>                                         to get its Registration
>>>                                             it straight. Their
>>>                                             should be no such thing
>>>                                             as a registrstion access
>>>                                             token!  Just the token
>>>                                             the client obtains to
>>>                                             update its profile
>>>                                             through the normal token
>>>                                             request process.
>>>                                                 normal token server
>>>                                                 no problem. (The
>>>                                                 explicitly but I
>>>                                                 would be willing to
>>>                                                 do so.) Or you could
>>>                                                 get it elsewhere.
>>>                                                 Doesn't matter, just
>>>                                                 like it doesn't
>>>                                                 matter with any
>>>                                                 other OAuth2
>>>                                                 Token, then having
>>>                                                 the token come from
>>>                                                 the token endpoint
>>>                                                 would require a lot
>>>                                                 more work and
>>>                                                 complexity on behalf
>>>                                                 of both of the
>>>                                                 Either you end up
>>>                                                 with public clients
>>>                                                 getting secrets they
>>>                                                 shouldn't need or
>>>                                                 with granting
>>>                                                 clients access to
>>>                                                 have it. Plus it
>>>                                                 adds extra round
>>>                                                 trips which don't
>>>                                                 buy you anything.
>>>                                                     The preference
>>>                                                     is to have the
>>>                                                     access token for
>>>                                                     server rather
>>>                                                     then by the
>>>                                                     obtained through
>>>                                                     a unique process
>>>                                                     and must outlive
>>>                                                     the client.
>>>                                                     at 19:47,
>>>                                                     "Richer, Justin
>>>                                                     P."
>>>                                                         understand
>>>                                                         any of the
>>>                                                         below -- it
>>>                                                         already *is*
>>>                                                         an OAuth2
>>>                                                         handling.
>>>                                                         Your access
>>>                                                         tokens can
>>>                                                         be
>>>                                                         used to
>>>                                                         access a
>>>                                                         normal
>>>                                                         resource.
>>>                                                         Full stop.
>>>                                                         Anything
>>>                                                         else is out
>>>                                                         of scope.
>>>                                                         The
>>>                                                         discussions
>>>                                                         at the
>>>                                                         beginning
>>>                                                         some ways
>>>                                                         you *could*
>>>                                                         use it and
>>>                                                         are
>>>                                                         non-normative and
>>>                                                         You seem to
>>>                                                         be asking
>>>                                                         for
>>>                                                         that's
>>>                                                         already in
>>>                                                         the draft.
>>>                                                         May 30, 2013
>>>                                                         7:31 PM
>>>                                                         2013-05-30,
>>>                                                             marked
>>>                                                             by [JR].
>>>                                                             30, 2013
>>>                                                             5:25 PM
>>>                                                             *Cc:*
>>>                                                             John
>>>                                                             <http://www.independentid.com/>
>>>
>>>                                                             [email-masked]
>>>                                                             2013-05-30,
>>>                                                             at 2:09
>>>                                                             PM,
>>>                                                             Richer
>>>                                                             think
>>>                                                             see part
>>>                                                             hang up.
>>>                                                             I have
>>>                                                             describe, where
>>>                                                             you
>>>                                                             3rd
>>>                                                             party
>>>                                                             token
>>>                                                             for a
>>>                                                             "local"
>>>                                                             have
>>>                                                             seen
>>>                                                             tokens
>>>                                                             are
>>>                                                             federated directly
>>>                                                             at the
>>>                                                             PR.
>>>                                                             with
>>>                                                             that

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:33:48 -0700 (PDT)

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

> Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.
It depends which case you are using.  If the developer is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure.  In this scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed.  But then, if this is your case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it.  So you are a developer and you want to build a client for a Microsoft or Oracle app.  You want to be able to ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token".    This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

===> For this to work, the contents and format of that token MUST be defined.   Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server?  Or any other combination of implementations from different vendors/communities?

> The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

> *any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.
> 
>> 
> Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.
> 
>  -- Justin
> 
>> 
>> Phil
>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:35:57 -0700

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back.  But that doesn't explain the issue.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

> I feel we're still just going in circles with these arguments, but my comments are inline:
> 
> [JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.
> 
> [JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.
> 
> [JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.
> 
> [JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration. 
> 
>> 
> [JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.
> 
>> 
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:36:32 -0400

... because it already *is* a REST protected API. It's protected with 
the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do 
with the REST protected API that it's protecting.

  -- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:
> Nobody has explained why using a normal REST protected API won't work. 
> You keep saying that and that you won't go back.  But that doesn't 
> explain the issue.
>
> Phil
>
> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>>>> FWIW, I just read the spec through with fresh eyes, and I found 
>>>>> the explanation of the workflow in 1.4.2 very useful.
>>>>>
>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or 
>>>> someone) getting a token through some other means, like browsing to 
>>>> a developer portal and getting a Bearer token. I've edited the 
>>>> example in 1.4.3 in the latest (unpublished) text so that the 
>>>> developer is literally doing OAuth2 to get the initial token. It's 
>>>> important to note that this could be any flavor of OAuth2 token, 
>>>> though Bearer tokens are of course the most common.
>>>>
>>>>> The bit about getting an access token specific to that 
>>>>> registration is a new flow (right?), but it seems convenient.
>>>>
>>>> Right, it's a new way to get a bearer token so that you can use it 
>>>> at the protected resource. We wanted to re-use the token endpoint 
>>>> for this, but couldn't come up with a reasonable way of doing so 
>>>> (as has been discussed on the list.
>>>
>>> the "registration endpoint".  Clients wanting to update their 
>>> profiles do the normal client token request flow to the token 
>>> endpoint to obtain a normal access token useable at the 
>>> "configuration endpoint".
>>>
>>
>> [JR] But then you're opening up the client_credentials flow to 
>> anonymous clients, or you've got to be able to lock down 
>> client_credentials as a flow to only a special (service-specific) 
>> scope for client configuration purposes. This, I think, is much more 
>> complicated to implement and much more error prone. I don't think 
>> it's even possible in the software stack we're building on top of. 
>> And furthermore, you're not letting public clients dynamically 
>> register anymore, since you'd be forcing everyone to have a client 
>> secret. Your dynamic public clients would have to save the client 
>> secret but know to only use it at the registration endpoint, and not 
>> the token endpoint where they're used to. This way, it's clear. You 
>> against expiring the tokens, and for good reason. But it's your 
>> choice to change that if you don't want longstanding read/edit access 
>> to a client's configuration.
>>
>>>  Because at the first seeming challenge, the WG create a new flow. 
>>> How do we expect implementers to behave?
>>
>> your analogy. Bearer tokens were, which is also the group's koolaid. 
>> We tried to go down the road you suggest and it was a dead end. Why 
>> do you think it will work better this time? And I'd like to point out 
>> a decision from several years ago now to separate the notion of "how 
>> you get a token" from "how you use a token" in OAuth2. OAuth1 had all 
>> of these rolled in together, and deployment experience showed us that 
>> that make sense on their own that let you build systems like this 
>> that also make sense.
>>
>> just a protected resource. Our implementation here literally just 
>> looks for the token on the way in in the auth layer and makes sure 
>> it's got a special service-specific scope that handles registration.
>>
>>>
>>> If the draft drops "registration access tokens", a lot of the text 
>>> in the draft disappears.  The whole spec is much simpler.
>>
>> dealing with the client metadata and the RESTful protocol for 
>> managing that. The registration access token is a mechanism for doing so.
>>
>>>
>>>>
>>>>> you get or use the Initial token, but giving it a special name 
>>>>> makes explaining a plausible workflow easier.
>>>>
>>>>> Having said that, I have trouble imagining the scenario where 
>>>>> you'd use the 1.4.1 flow, but that may be because of my 
>>>>> Google-centric worldview.
>>>>
>>>>> And I’m not sure 1.4.3 adds any value at all.  It just seems to be 
>>>>> a matter of different ways you could get and make use of the 
>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the 
>>>> current working text is make the initial process of getting the 
>>>> Initial Access Token different (the developer now uses OAuth2 to 
>>>> configure their build environment). The *real* important difference 
>>>> that's being shown here, though, is that the client doesn't call 
>>>> the registration endpoint, the developer (and their build 
>>>> environment) does. So yes, it's exactly all about how you get and 
>>>> use the registration access token. There are plenty of other ways 
>>>> to do it as well, so that's why this section was a non-normative 
>>>> set of examples. To facilitate that understanding, I've moved it to 
>>>> an appendix in the working copy of draft -12.
>>>>
>>>> Thanks,
>>>>  -- Justin
>>>>
>>>>>  -T
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       * To be clear, Draft 11 has the same Registration Access
>>>>>     Token system that has been in place since draft 01, it is not
>>>>>     inventing something new at the last minute as could be
>>>>>     inferred from the statement below.
>>>>>
>>>>>     regarding Registration Access Tokens that wasn’t in the
>>>>>     initial draft.  It appears because Phil hasn’t been following
>>>>>     the proposed drafts until the last call he is now raising an
>>>>>     issue no one in the WG saw as an issue.  That’s not to say his
>>>>>     point isn’t valid, but the discussion continues to go all over
>>>>>     the map between “local” and “federated” tokens, usage of the
>>>>>     RFC6749 “Token” endpoint, etc.  It would be great if all of
>>>>>     Phil’s points could be addressed in priority
>>>>>       * DynReg is using an absolutely standard OAuth 2 Bearer
>>>>>     token as the Registration Access Token, it's just not coming
>>>>>     from a Token Endpoint. However, since an OAuth Protected
>>>>>     Resource doesn't care where its tokens come from so long as it
>>>>>     can validate them, I don't see this as a problem -- this is a
>>>>>     key point where Phil and I disagree.
>>>>>
>>>>>     which does not    discuss dynamic registration.  Phil’s point
>>>>>     as I understand it is that there should be no difference
>>>>>     between an access token used to access resource owner
>>>>>     protected data and the registration structure, which I do not
>>>>>     agree with.  As I said in the previous
>>>>>     access to resource owner protected data just because a client
>>>>>     is creating a registration with an AS.  This would be the
>>>>>     situation if the client credential flow is used to register an
>>>>>     application.  Since our
>>>>>     a circular exchange now for the past few days without any
>>>>>             FWIW I believe that is a significantly strong reason
>>>>>             to differentiate an access token that can access the
>>>>>             access token obtained through the client credential
>>>>>             flow to mean it has the ability to update a
>>>>>             registration, when a user may not want it to have
>>>>>             access to protected data will only increase both the
>>>>>             complexity of the access tokens as well as make their
>>>>>             usage harder to explain to non-technical individuals
>>>>>             who have to understand the differences between the
>>>>>             access tokens obtained through the various flows.
>>>>>
>>>>>
>>>>>             Just my two cents.
>>>>>
>>>>>
>>>>>             Best regards,
>>>>>
>>>>>             Don
>>>>>
>>>>>             Donald F. Coffin
>>>>>
>>>>>             Founder/CTO
>>>>>
>>>>>
>>>>>             REMI Networks
>>>>>
>>>>>             current form. Yes it gives each execution instance a
>>>>>             new id, but that isnt what sp's want. It is a huge
>>>>>             attack and management headache. Eliminate or propose a
>>>>>             different solution.
>>>>>
>>>>>             Phil
>>>>>
>>>>>
>>>>>                         But the outstanding question is: how do
>>>>>                         you get the access token to access the
>>>>>                         created resource (IE: the Registration
>>>>>                         Access Token)? You can't use the
>>>>>                             token to create a new resource. You
>>>>>                             just need one to access one. That is
>>>>>                             just basic security config.
>>>>>
>>>>>
>>>>>                             Phil
>>>>>
>>>>>
>>>>>                                 isn't addressed by what you
>>>>>                                 suggest doing, below. I also
>>>>>                                 Registration Access Token but
>>>>>                                 using some other token method
>>>>>                                 would actually make the spec
>>>>>                                 larger, though I'd be glad to
>>>>>                                 if you'd like to write one. And
>>>>>                                 the fact that OIDC is doing it
>>>>>                                 this way, and considered but
>>>>>                                 describing, should say something
>>>>>                                 to the WG here about whether or
>>>>>                                 not this is the right choice.
>>>>>                                 Rough consensus and running code,
>>>>>                                 after all.
>>>>>
>>>>>                                 We'll move to the next draft in
>>>>>                                 the last call process shortly, as
>>>>>                                 I have a handful of non-normative
>>>>>                                 editorial changes that I need to
>>>>>                                 make, thanks to feedback from a
>>>>>                                 few folks.
>>>>>
>>>>>                                 review, Phil, and I look forward
>>>>>                                 to future feedback.
>>>>>
>>>>>                                  -- Justin
>>>>>
>>>>>                                     does it this way. But that is
>>>>>                                     a political reason, not a
>>>>>                                     technical reason. Still,
>>>>>                                     compatibility is always a
>>>>>                                     strong objective.  Even so,
>>>>>                                     oidc could keep using their
>>>>>                                     update prior to expiry? It
>>>>>                                     makes no sense to have another
>>>>>                                     token with longer expiry.
>>>>>                                     B'sides, even expired the
>>>>>                                     Why force the client to
>>>>>                                     persist multiple tokens and
>>>>>                                     creds? That is far far too
>>>>>                                     complex.
>>>>>
>>>>>
>>>>>                                     Apologies for my rant. Maybe
>>>>>                                     we should park this for now.
>>>>>                                     We are going in circles.
>>>>>
>>>>>                                     Phil
>>>>>
>>>>>
>>>>>                                     On 2013-05-31, at 11:25,
>>>>>                                     Justin Richer
>>>>>                                     <[email-masked]
>>>>>                                         you to be clear about
>>>>>                                         which part you're
>>>>>                                         objecting to because the
>>>>>                                         answers are different.
>>>>>                                         component we're talking
>>>>>                                         about. I'm sure you'd
>>>>>                                         agree than in
>>>>>                                         this, precision of
>>>>>                                         language and labels is key
>>>>>                                         for communication between
>>>>>                                         "Registration Access
>>>>>                                         Token" you can know that I
>>>>>                                         mean a very specific
>>>>>                                         thing, and when I say
>>>>>                                         "Initial Registration
>>>>>                                         Token" I mean a very
>>>>>                                         different specific thing.
>>>>>                                         So I'm asking you, please,
>>>>>                                         use the defined terms so
>>>>>                                         that we can avoid this
>>>>>                                         unnecessary confusion.
>>>>>
>>>>>                                         But anyway, what you're
>>>>>                                         update is profile" *IS*
>>>>>                                         the Registration Access
>>>>>                                         Token. That's all that
>>>>>                                         that token is used for.
>>>>>                                         You're not asking for it
>>>>>                                         to go away, you're asking
>>>>>                                         for it to come from the
>>>>>                                         Token Endpoint instead of
>>>>>                                         the response from the
>>>>>                                         Registration Endpoint. I
>>>>>                                         don't see how the client
>>>>>                                         *can* get it from the
>>>>>                                         normal token process
>>>>>                                         without jumping through
>>>>>                                         specialized hoops to make
>>>>>                                         that happen. I've
>>>>>                                         implemented the draft the
>>>>>                                         way that it is right now,
>>>>>                                         both client and server
>>>>>                                         We've done interop
>>>>>                                         testing, and it works.
>>>>>                                         This is a proven pattern
>>>>>                                         and from where I sit there
>>>>>                                         is both rough consensus
>>>>>                                         and running code.
>>>>>
>>>>>                                         I believe that I've
>>>>>                                         already pointed out how
>>>>>                                         the solutions you've
>>>>>                                         proposed so far won't work
>>>>>                                         in practice, for various
>>>>>                                         reasons, many of which
>>>>>                                         have already been brought
>>>>>                                         up and discussed
>>>>>                                         previously. If you have
>>>>>                                         Access Token, please
>>>>>                                         propose it; but I haven't
>>>>>                                         seen anything yet that
>>>>>                                         will fly.
>>>>>
>>>>>                                          -- Justin
>>>>>
>>>>>                                         On 05/31/2013 11:10 AM,
>>>>>                                         Phil Hunt wrote:
>>>>>
>>>>>                                             Justin,
>>>>>
>>>>>
>>>>>                                             This is my primary
>>>>>                                             objection! We can't
>>>>>                                             keep it straight.
>>>>>                                             Their should be no
>>>>>                                             such thing as a
>>>>>                                             registrstion access
>>>>>                                             token!  Just the token
>>>>>                                             the client obtains to
>>>>>                                             update its profile
>>>>>                                             through the normal
>>>>>                                             token request process.
>>>>>
>>>>>                                             Phil
>>>>>
>>>>>
>>>>>                                             On 2013-05-31, at
>>>>>                                             10:55, Justin Richer
>>>>>                                             <[email-masked]
>>>>>                                                 Initial
>>>>>                                                 Registration
>>>>>                                                 Token, then you
>>>>>                                                 could get that
>>>>>                                                 through the normal
>>>>>                                                 token server no
>>>>>                                                 don't call this
>>>>>                                                 out explicitly but
>>>>>                                                 I would be willing
>>>>>                                                 to do so.) Or you
>>>>>                                                 could get it
>>>>>                                                 matter, just like
>>>>>                                                 it doesn't matter
>>>>>                                                 with any other
>>>>>                                                 Registration
>>>>>                                                 Access Token, then
>>>>>                                                 having the token
>>>>>                                                 come from the
>>>>>                                                 token endpoint
>>>>>                                                 would require a
>>>>>                                                 lot more work and
>>>>>                                                 complexity on
>>>>>                                                 behalf of both of
>>>>>                                                 the client and
>>>>>                                                 server. Either you
>>>>>                                                 end up with public
>>>>>                                                 clients getting
>>>>>                                                 secrets they
>>>>>                                                 On 05/31/2013
>>>>>                                                 10:15 AM, Phil
>>>>>                                                     access token
>>>>>                                                     obtained
>>>>>                                                     through a
>>>>>                                                     unique process
>>>>>                                                     and must
>>>>>                                                     outlive the
>>>>>                                                         below --
>>>>>                                                         it already
>>>>>                                                         *is* an
>>>>>                                                         OAuth2
>>>>>                                                         without
>>>>>                                                         any
>>>>>                                                         Your
>>>>>                                                         long-lived, federated,
>>>>>                                                         structured, random
>>>>>                                                         blobs ...
>>>>>                                                         totally
>>>>>                                                         matter.
>>>>>                                                         They are
>>>>>                                                         being used
>>>>>                                                         to access
>>>>>                                                         else is
>>>>>                                                         out of
>>>>>                                                         examples
>>>>>                                                         of some
>>>>>                                                         ways you
>>>>>                                                         *could*
>>>>>                                                         You seem
>>>>>                                                         to be
>>>>>                                                         2013 7:31 PM
>>>>>                                                         16:11,
>>>>>                                                             inline, marked
>>>>>                                                             *Sent:* Thursday,
>>>>>                                                             May
>>>>>                                                             30,
>>>>>                                                             2013
>>>>>                                                             Richer, Justin
>>>>>                                                             P.
>>>>>                                                             at
>>>>>                                                             2:09
>>>>>                                                             see
>>>>>                                                             part
>>>>>                                                             hang
>>>>>                                                             up. I
>>>>>                                                             not
>>>>>                                                             trade
>>>>>                                                             a 3rd
>>>>>                                                             "local" token.
>>>>>                                                             lets
>>>>>                                                             you do
>>>>>                                                             some

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:37:18 -0400

Interoperability of the processing of OAuth tokens is a separate issue 
that needs to be solved not just for registration. When it is solved in 
the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), 
then you're locked to whatever process you want to use to 
verify/validate that token. Since it's just an OAuth token, you've got a 
number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than 
just try to cram something into registration.

  -- Justin

On 06/06/2013 01:33 PM, Phil Hunt wrote:
>> Phil, as I and several others have explained previously, that's not 
>> true at all. It's a token that gives authorization to the 
>> registration endpoint. The fact that you can use it as an assertion 
>> to pass along signed claims is an artifact of it being an OAuth token 
>> and an OAuth token is an opaque string. Please read through the 
>> dynamic registration draft again -- it says absolutely nothing about 
>> assertions, signatures, or claims with regard to this token.
> It depends which case you are using.  If the developer is talking to a 
> single deployment domain and obtains an initial access token and then 
> ships it with all clients, then sure.  In this scenario, the contents 
> are totally controlled by the local domain.
>
> I agree. In this case, you don't care about inter-op. The whole 
> environment is siloed.  But then, if this is your case, I'm not sure 
> why this draft is at the IETF.
>
> The interoperability case is where a third party generates that 
> assertion and the deployment domain has to decide to accept it.  So 
> you are a developer and you want to build a client for a Microsoft or 
> Oracle app.  You want to be able to ship that to your customers. You 
> register with the appropriate publisher and they give you a signed 
> assertion that can be used as the "Initial Access Token".    This 
> token is then accepted by the deployment domain and then it decides if 
> it trusts the signer or not.
>
> ===> For this to work, the contents and format of that token MUST be 
> defined.   Otherwise how could we ensure a Microsoft signed assertion 
> would be accepted by a PingIdentity OAuth server?  Or any other 
> combination of implementations from different vendors/communities?
>
>>
>>>
>>> Bearer or not bearer is a distraction. The fact that the contents 
>>> and format of this token is out of scope leaves a HUGE interop gap.
>>
> [PH] I was reacting to John Bradley's assertion that the spec was 
> narrowly defined with interop in mind. Yet this mechanism is a key 
> factor being used to share information about the software.
>
>>
>>>
>> *any* parameter on the client, including the 
>> registration_access_token and any extension parameters, can be 
>> rotated on any call to the Read or Update methods (except for 
>> client_id). So if you've got another mechanism for doing client 
>> authentication, you can rotate that, too.
>>
>>>
>> secrets (using jwks_uri to register public keys), I have to 
>> empirically disagree with that statement.
>>
>>  -- Justin
>>
>>>
>>> Phil
>>>
>>>> I am not opposed to having this extended at some point in the 
>>>> future, once we have a second token type.   The new token type 
>>>> should be available to do updates as well.
>>>>
>>>> The problem is that starting down the HoK route potentially 
>>>> requires a registered client that may need to be registered to do 
>>>> the registration.
>>>>> Because bearer tokens have a stable RFC-numbered spec and are 
>>>>> widely implemented and the registration flow as documented seems 
>>>>> like it should work?  -T
>>>>> That’s the answer for why there is support for bearer tokens but 
>>>>> it is not the answer to why that’s the only supported mechanism.
>>>>> If we want to support stronger security mechanisms (which the 
>>>>> group has decided to work on already) then we need to have a story 
>>>>> on how to support the other mechanisms as well .

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:43:53 -0700 (PDT)

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) flows.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:36 AM, Justin Richer wrote:

> ... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token. 
> 
> The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:47:04 -0400

Because anonymous *registration* and public client *access* to the token 
endpoint are two different things.

  -- Justin

On 06/06/2013 01:43 PM, Phil Hunt wrote:
> This means the configuration endpoints can use normal access tokens 
> obtained through RFC6749 section 4.4 (Client Auth) flows.
>
> Phil
>
> @independentid
>> The *only* difference is how you get the token, which has nothing to 
>> do with the REST protected API that it's protecting.
>>
>>  -- Justin
>>
>>> Nobody has explained why using a normal REST protected API won't 
>>> work. You keep saying that and that you won't go back.  But that 
>>> doesn't explain the issue.
>>>
>>> Phil
>>>
>>> @independentid
>>>>>>> - you use that “Initial token” token to register, in exchange 
>>>>>>> you get the client-id & so on, and also a a per-registration 
>>>>>> someone) getting a token through some other means, like browsing 
>>>>>> to a developer portal and getting a Bearer token. I've edited the 
>>>>>> developer is literally doing OAuth2 to get the initial token. 
>>>>>> It's important to note that this could be any flavor of OAuth2 
>>>>>> token, though Bearer tokens are of course the most common.
>>>>>>
>>>>>> Right, it's a new way to get a bearer token so that you can use 
>>>>>> it at the protected resource. We wanted to re-use the token 
>>>>>> endpoint for this, but couldn't come up with a reasonable way of 
>>>>>> doing so (as has been discussed on the list.
>>>>>
>>>>> "registration endpoint" and the "configuration endpoint".  A 
>>>>> server accepting anonymous registration simply accepts anonymous 
>>>>> access at the "registration endpoint".  Clients wanting to update 
>>>>> their profiles do the normal client token request flow to the 
>>>>> token endpoint to obtain a normal access token useable at the 
>>>> scope for client configuration purposes. This, I think, is much 
>>>> more complicated to implement and much more error prone. I don't 
>>>> think it's even possible in the software stack we're building on 
>>>> top of. And furthermore, you're not letting public clients 
>>>> dynamically register anymore, since you'd be forcing everyone to 
>>>> have a client secret. Your dynamic public clients would have to 
>>>> save the client secret but know to only use it at the registration 
>>>> endpoint, and not the token endpoint where they're used to. This 
>>>> way, it's clear. You get a token that you use at a given endpoint, 
>>>> the end.
>>>>
>>>>> 1.  No need to keep "registration access token" around 
>>>>> indefinitely. It's just an access token.  In fact it is only 
>>>>> needed for minutes since it will likely only be used to read or 
>>>>> update profiles or to perform client initiated credential rotation.
>>>>
>>>> [JR] You *can* throw away your registration access tokens if you 
>>>> want to, or have them expire, if you want to limit the lifespan of 
>>>> your clients. It's only the security considerations section that 
>>>> suggests against expiring the tokens, and for good reason. But it's 
>>>> your choice to change that if you don't want longstanding read/edit 
>>>> access to a client's configuration.
>>>>
>>>> [JR] That particular koolaid wasn't the right drink here, to 
>>>> stretch your analogy. Bearer tokens were, which is also the group's 
>>>> koolaid. We tried to go down the road you suggest and it was a dead 
>>>> end. Why do you think it will work better this time? And I'd like 
>>>> to point out a decision from several years ago now to separate the 
>>>> notion of "how you get a token" from "how you use a token" in 
>>>> OAuth2. OAuth1 had all of these rolled in together, and deployment 
>>>> experience showed us that people didn't really want to use it that 
>>>> way. People want components that make sense on their own that let 
>>>> you build systems like this that also make sense.
>>>>
>>>> [JR] It already is. Protected resources don't care where you get 
>>>> your tokens from, just that you have them, so from that perspective 
>>>> it is just a protected resource. Our implementation here literally 
>>>> just looks for the token on the way in in the auth layer and makes 
>>>> sure it's got a special service-specific scope that handles 
>>>> registration.
>>>>
>>>>>
>>>> [JR] Much simpler, perhaps, but much less functional and useful. 
>>>> And honestly, not much of the text actually goes away. Most of the 
>>>> draft isn't about dealing with the registration access token, it's 
>>>> about dealing with the client metadata and the RESTful protocol for 
>>>>>>>   From an OAuth 2 point of view, there's nothing special about 
>>>>>>> how you get or use the Initial token, but giving it a special 
>>>>>>> name makes explaining a plausible workflow easier.
>>>>>>
>>>>>> Right, and I've admitted that "Initial Access Token" a crappy 
>>>>>> name, but I haven't heard a better suggestion yet.
>>>>>>
>>>>>>>
>>>>>> Could be -- but if Google wants to be an open-registration 
>>>>>> identity provider (like it has been with OpenID 2.0), it will 
>>>>>> need to handle this flow as well. This is the client acting on 
>>>>>> its own behalf, showing up and saying "hi, I'm a client!" and 
>>>>>> that's that. I think this is a very important case for 
>>>>>> interoperability of dynamic registration.
>>>>>>
>>>>>>>
>>>>>>> And I’m not sure 1.4.3 adds any value at all.  It just seems to 
>>>>>>> be a matter of different ways you could get and make use of the 
>>>>>>> interesting combinations that haven't been thought of there. 
>>>>>>>  I'd just lose 1.4.3.
>>>>>>>
>>>>>>
>>>>>> configure their build environment). The *real* important 
>>>>>> difference that's being shown here, though, is that the client 
>>>>>> doesn't call the registration endpoint, the developer (and their 
>>>>>> build environment) does. So yes, it's exactly all about how you 
>>>>>> get and use the registration access token. There are plenty of 
>>>>>> other ways to do it as well, so that's why this section was a 
>>>>>> non-normative set of examples. To facilitate that understanding, 
>>>>>> I've moved it to an appendix in the working copy of draft -12.
>>>>>>
>>>>>> Thanks,
>>>>>>  -- Justin
>>>>>>
>>>>>>>  -T
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Token system that has been in place since draft 01, it is
>>>>>>>     not inventing something new at the last minute as could be
>>>>>>>     [DFC]  I agree with Justin.  There is nothing new in draft
>>>>>>>     11 regarding Registration Access Tokens that wasn’t in the
>>>>>>>     initial draft.  It appears because Phil hasn’t been
>>>>>>>     following the proposed drafts until the last call he is now
>>>>>>>     raising an issue no one in the WG saw as an issue. That’s
>>>>>>>     not to say his point isn’t valid, but the discussion
>>>>>>>     continues to go all over the map between “local” and
>>>>>>>     “federated” tokens, usage of the RFC6749 “Token” endpoint,
>>>>>>>     etc.  It would be great if all of Phil’s points could be
>>>>>>>     addressed in priority
>>>>>>>     Resource doesn't care where its tokens come from so long as
>>>>>>>     it can validate them, I don't see this as a problem -- this
>>>>>>>     is a key point where Phil and I disagree.
>>>>>>>
>>>>>>>     proposal from Phil that would describe the differences
>>>>>>>     between the two perspectives other than to say that the
>>>>>>>     Dynamic Registration should use the Token endpoint defined
>>>>>>>     in RFC6749, which does not    discuss dynamic registration.
>>>>>>>     Phil’s point as I understand it is that there should be no
>>>>>>>     difference between an access token used to access resource
>>>>>>>     owner protected data and the registration structure, which I
>>>>>>>     do not agree with. As I said in the previous
>>>>>>>     resource owner protected data just because a client is
>>>>>>>     creating a registration with an AS.  This would be the
>>>>>>>     situation if the client credential flow is used to register
>>>>>>>     an application.  Since our
>>>>>>>     case is one we have elected NOT to support.
>>>>>>>
>>>>>>>                 [DFC]  I repeat my initial comment, this
>>>>>>>     conversation has been a circular exchange now for the past
>>>>>>>     few days without any appearance of an alternative option to
>>>>>>>     resolve the issues.
>>>>>>>
>>>>>>>
>>>>>>>      -- Justin
>>>>>>>
>>>>>>>         I am not proposing any change in meaning. If
>>>>>>>         registration acces token issues by normal token server
>>>>>>>         with scope registration everything is clear as it is for
>>>>>>>         any other protected API. Draft 11 invents a whole new
>>>>>>>         system. I strongly disagree with this.
>>>>>>>
>>>>>>>         Phil
>>>>>>>
>>>>>>>
>>>>>>>             For something that was agreed to be parked a few
>>>>>>>             hours ago, there sure seems to still be a lot of
>>>>>>>             circular discussion. Should we ask a mediator to
>>>>>>>             intervene?
>>>>>>>
>>>>>>>
>>>>>>>             registration information without having the ability
>>>>>>>             to access protected data. Especially given the
>>>>>>>             implied strength of the “client credential” obtained
>>>>>>>             access token. I have found it extremely confusing to
>>>>>>>             users when explaining the difference between an
>>>>>>>             access token obtained thorough an authorization code
>>>>>>>             flow and a client credential flow, simply because
>>>>>>>             they are both called an “access token”. Changing the
>>>>>>>             meaning of an access token obtained through the
>>>>>>>             client credential flow to mean it has the ability to
>>>>>>>             update a registration, when a user may not want it
>>>>>>>             to have access to protected data will only increase
>>>>>>>             both the complexity of the access tokens as well as
>>>>>>>             make their usage harder to explain to non-technical
>>>>>>>             individuals who have to understand the differences
>>>>>>>             between the access tokens obtained through the
>>>>>>>             various flows.
>>>>>>>
>>>>>>>
>>>>>>>             Just my two cents.
>>>>>>>
>>>>>>>
>>>>>>>             Best regards,
>>>>>>>
>>>>>>>             Don
>>>>>>>
>>>>>>>             Donald F. Coffin
>>>>>>>
>>>>>>>             Founder/CTO
>>>>>>>
>>>>>>>
>>>>>>>             REMI Networks
>>>>>>>
>>>>>>>             2. Support for implicit clients needs to be
>>>>>>>             discussed. The current proposal creates large
>>>>>>>             negative value for the service provider and most
>>>>>>>             would never allow in current form. Yes it gives each
>>>>>>>             execution instance a new id, but that isnt what sp's
>>>>>>>             want. It is a huge attack and management headache.
>>>>>>>             Eliminate or propose a different solution.
>>>>>>>
>>>>>>>             Phil
>>>>>>>
>>>>>>>
>>>>>>>                     credential is an implicit client. An
>>>>>>>                     implicit client is transient and so would
>>>>>>>                     never update.
>>>>>>>
>>>>>>>                             Even simpler. You don't need an
>>>>>>>                             access token to create a new
>>>>>>>                             resource. You just need one to
>>>>>>>                             access one. That is just basic
>>>>>>>                             security config.
>>>>>>>
>>>>>>>
>>>>>>>                             Phil
>>>>>>>
>>>>>>>
>>>>>>>                             On 2013-05-31, at 12:34, Justin
>>>>>>>                                 circles, since I just was going
>>>>>>>                                 to bring up my counter argument
>>>>>>>                                 of "what about clients with no
>>>>>>>                                 credentials?" again, which
>>>>>>>                                 *still* isn't addressed by what
>>>>>>>                                 you suggest doing, below. I also
>>>>>>>                                 review a concrete
>>>>>>>                                 counter-proposal if you'd like
>>>>>>>                                 to write one. And the fact that
>>>>>>>                                 OIDC is doing it this way, and
>>>>>>>                                 considered but rejected the way
>>>>>>>                                 that you're describing, should
>>>>>>>                                 say something to the WG here
>>>>>>>                                 about whether or not this is the
>>>>>>>                                 right choice. Rough consensus
>>>>>>>                                 the last call process shortly,
>>>>>>>                                 as I have a handful of
>>>>>>>                                 non-normative editorial changes
>>>>>>>                                     There is absolutely no need
>>>>>>>                                     for a registration access
>>>>>>>                                     token.
>>>>>>>
>>>>>>>
>>>>>>>                                     access tokens as per 6749.
>>>>>>>                                     If you can't follow 6749 and
>>>>>>>                                     need new issuing methods,
>>>>>>>                                     what are others to say
>>>>>>>                                     I have not heard a good
>>>>>>>                                     reason for the special
>>>>>>>                                     process or one good enough
>>>>>>>                                     to warrant a new method for
>>>>>>>                                     issuing an access token.
>>>>>>>                                     Does the broader group
>>>>>>>                                     realize this is what the
>>>>>>>                                     spec says?
>>>>>>>
>>>>>>>
>>>>>>>                                     Yes, i heard a lot saying
>>>>>>>                                     OIDC does it this way. But
>>>>>>>                                     that is a political reason,
>>>>>>>                                     not a technical reason.
>>>>>>>                                     Still, compatibility is
>>>>>>>                                     always a strong objective.
>>>>>>>                                      Even so, oidc could keep
>>>>>>>                                     using their method just
>>>>>>>                                     expiry of client creds.
>>>>>>>                                     Well, why not require the
>>>>>>>                                     client to update prior to
>>>>>>>                                     expiry? It makes no sense to
>>>>>>>                                     have another token with
>>>>>>>                                     longer expiry. B'sides, even
>>>>>>>                                     expired the client can
>>>>>>>                                     registration access token
>>>>>>>                                     the spec size will drop
>>>>>>>                                     roughly in half IMO. This
>>>>>>>                                     suggests simplicity to me.
>>>>>>>
>>>>>>>
>>>>>>>                                         We *can* keep it
>>>>>>>                                         straight just fine, but
>>>>>>>                                         I just need you to be
>>>>>>>                                         clear about which part
>>>>>>>                                         you're objecting to
>>>>>>>                                         different. Please use
>>>>>>>                                         the terms as defined in
>>>>>>>                                         the document so that we
>>>>>>>                                         all know which component
>>>>>>>                                         we're talking about. I'm
>>>>>>>                                         sure you'd agree than in
>>>>>>>                                         specification work such
>>>>>>>                                         as this, precision of
>>>>>>>                                         language and labels is
>>>>>>>                                         key for communication
>>>>>>>                                         between parties. This is
>>>>>>>                                         precisely why there's a
>>>>>>>                                         Terminology section
>>>>>>>                                         right up front, so that
>>>>>>>                                         when I say "Registration
>>>>>>>                                         Access Token" you can
>>>>>>>                                         know that I mean a very
>>>>>>>                                         specific thing, and when
>>>>>>>                                         I say "Initial
>>>>>>>                                         Registration Token" I
>>>>>>>                                         mean a very different
>>>>>>>                                         specific thing. So I'm
>>>>>>>                                         asking you, please, use
>>>>>>>                                         the defined terms so
>>>>>>>                                         talking about below,
>>>>>>>                                         "the token the client
>>>>>>>                                         uses to update is
>>>>>>>                                         profile" *IS* the
>>>>>>>                                         to go away, you're
>>>>>>>                                         asking for it to come
>>>>>>>                                         instead of the response
>>>>>>>                                         from the Registration
>>>>>>>                                         Endpoint. I don't see
>>>>>>>                                         how the client *can* get
>>>>>>>                                         it from the normal token
>>>>>>>                                         process without jumping
>>>>>>>                                         through specialized
>>>>>>>                                         hoops to make that
>>>>>>>                                         happen. I've implemented
>>>>>>>                                         the draft the way that
>>>>>>>                                         it is right now, both
>>>>>>>                                         client and server side,
>>>>>>>                                         and it works. Others
>>>>>>>                                         have implemented it,
>>>>>>>                                         too. We've done interop
>>>>>>>                                         and from where I sit
>>>>>>>                                         there is both rough
>>>>>>>                                         consensus and running code.
>>>>>>>
>>>>>>>                                         I believe that I've
>>>>>>>                                         already pointed out how
>>>>>>>                                         the solutions you've
>>>>>>>                                         proposed so far won't
>>>>>>>                                         work in practice, for
>>>>>>>                                         various reasons, many of
>>>>>>>                                         which have already been
>>>>>>>                                         brought up and discussed
>>>>>>>                                         previously. If you have
>>>>>>>                                         another way for the
>>>>>>>                                         client to get its
>>>>>>>                                         Registration Access
>>>>>>>                                         Token, please propose
>>>>>>>                                         it; but I haven't seen
>>>>>>>                                             token!  Just the
>>>>>>>                                             token the client
>>>>>>>                                             obtains to update
>>>>>>>                                             its profile through
>>>>>>>                                             the normal token
>>>>>>>                                                 Which token are
>>>>>>>                                                 you referring to
>>>>>>>                                                 here?
>>>>>>>                                                 through the
>>>>>>>                                                 server no
>>>>>>>                                                 writeups don't
>>>>>>>                                                 call this out
>>>>>>>                                                 would be willing
>>>>>>>                                                 to do so.) Or
>>>>>>>                                                 you could get it
>>>>>>>                                                 elsewhere.
>>>>>>>                                                 Doesn't matter,
>>>>>>>                                                 just like it
>>>>>>>                                                 doesn't matter
>>>>>>>                                                 Access Token,
>>>>>>>                                                 then having the
>>>>>>>                                                 token come from
>>>>>>>                                                 the token
>>>>>>>                                                 endpoint would
>>>>>>>                                                 require a lot
>>>>>>>                                                 behalf of both
>>>>>>>                                                 of the client
>>>>>>>                                                 and server.
>>>>>>>                                                 Either you end
>>>>>>>                                                 up with public
>>>>>>>                                                 shouldn't need
>>>>>>>                                                 or with granting
>>>>>>>                                                 clients access
>>>>>>>                                                 to the
>>>>>>>                                                 shouldn't
>>>>>>>                                                 actually have
>>>>>>>                                                 it. Plus it adds
>>>>>>>                                                 extra round
>>>>>>>                                                 trips which
>>>>>>>                                                 don't buy you
>>>>>>>                                                     preference
>>>>>>>                                                     is to have
>>>>>>>                                                     the access
>>>>>>>                                                     issued by
>>>>>>>                                                     the normal
>>>>>>>                                                     token server
>>>>>>>                                                     rather then
>>>>>>>                                                     In the
>>>>>>>                                                     current
>>>>>>>                                                     unique
>>>>>>>                                                     process and
>>>>>>>                                                     must outlive
>>>>>>>                                                         any of
>>>>>>>                                                         it
>>>>>>>                                                         already
>>>>>>>                                                         protected resource
>>>>>>>                                                         random
>>>>>>>                                                         blobs
>>>>>>>                                                         ...
>>>>>>>                                                         being
>>>>>>>                                                         scope.
>>>>>>>                                                         lifecycle discussions
>>>>>>>                                                         beginning are
>>>>>>>                                                         merely
>>>>>>>                                                         use it
>>>>>>>                                                         asking
>>>>>>>                                                         something that's
>>>>>>>                                                         already
>>>>>>>                                                         in the
>>>>>>>                                                         draft.
>>>>>>>                                                             See
>>>>>>>                                                             below.
>>>>>>>                                                             OK,
>>>>>>>                                                             I
>>>>>>>                                                             of
>>>>>>>                                                             up.
>>>>>>>                                                             I
>>>>>>>                                                             party token
>>>>>>>                                                             a
>>>>>>>                                                             token.
>>>>>>>                                                             I
>>>>>>>                                                             where access
>>>>>>>                                                             do

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:48:21 -0700

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens.  This is for "registration" and does not constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:
http://tools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

> Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.
> 
> So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).
> 
> I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:48:29 -0400

I thought we were talking about the registration access token, not the 
initial access token?

  -- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote:
> This is why this to-MAY-to vs. to-MAH-to distinction around is the 
> initial access token an authorization token is important.
>
> The purpose for the initial access token is dramatically different 
> then normal access tokens.  This is for "registration" and does not 
> constitute authentication or authorization.
>
> Therefore, in this case, I do not believe that defining access tokens 
> in the broader sense makes this issue clearer.
>
> This might be a good paper to look at so the group understands why I 
> am differentiating authorization from what is happening with initial 
> access:
>> Interoperability of the processing of OAuth tokens is a separate 
>> issue that needs to be solved not just for registration. When it is 
>> solved in the wider case, Registration as-is will inherit the solution.
>>
>> So today, if you're using an Initial Access Token (which is 
>> optional), then you're locked to whatever process you want to use to 
>> verify/validate that token. Since it's just an OAuth token, you've 
>> got a number of things that you can do (assertions, introspection, 
>> magic).
>>
>> I'd rather we solve the *real* cross-domain issue in the wider case 
>> than just try to cram something into registration.
>>
>>  -- Justin
>>
>>>>> As I've said before the initial auth token should nothing to do 
>>>>> with auth. It is simply an assertion given to the developer to 
>>>>> distribute in order to pass on signed claims about the software.
>>>>
>>>> to pass along signed claims is an artifact of it being an OAuth 
>>>> token and an OAuth token is an opaque string. Please read through 
>>>> the dynamic registration draft again -- it says absolutely nothing 
>>>> about assertions, signatures, or claims with regard to this token.
>>> It depends which case you are using.  If the developer is talking to 
>>> a single deployment domain and obtains an initial access token and 
>>> then ships it with all clients, then sure.  In this scenario, the 
>>> contents are totally controlled by the local domain.
>>>
>>> you are a developer and you want to build a client for a Microsoft 
>>> or Oracle app.  You want to be able to ship that to your customers. 
>>> You register with the appropriate publisher and they give you a 
>>> signed assertion that can be used as the "Initial Access Token".   
>>>  This token is then accepted by the deployment domain and then it 
>>> decides if it trusts the signer or not.
>>>
>>> defined.   Otherwise how could we ensure a Microsoft signed 
>>> assertion would be accepted by a PingIdentity OAuth server?  Or any 
>>> other combination of implementations from different vendors/communities?
>>>
>>>>
>>>>>
>>>> The fact that some of us (myself included) are *using* this token 
>>>> to carry this kind of information is out of scope for the basic 
>>>> registration spec. I completely agree that there's value in 
>>>> defining this stuff, but as a separate and complementary spec from 
>>>> registration.
>>>
>>>>> Finally never-mind bearer bias, how are  client credentials 
>>>>> rotated interoperably if the only thing rotated is client_secret?
>>>>
>>>>> I would say the spec only works for client secrets and/or 
>>>>> all-in-one domain where there is no interop.
>>>>
>>>> Considering I've personally used it across domains and without 
>>>> client secrets (using jwks_uri to register public keys), I have to 
>>>>>> One criticism Hannes and others make of OAuth specs is they are 
>>>>>> not tightly profiled enough to be interoperable without further 
>>>>>> out of band configuration and profiling.
>>>>>>
>>>>>>> group has decided to work on already) then we need to have a 
>>>>>>> story on how to support the other mechanisms as well .

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:49:33 -0700

Huh?

There's no need for public clients to access the token endpoint as they can register anonymously.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:47 AM, Justin Richer wrote:

> Because anonymous *registration* and public client *access* to the token endpoint are two different things.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:49:57 -0400

Then how do they get their equivalent of a registration access token to 
manage their configurations?

The draft proposes that they get this token right from the registration 
endpoint. You're proposing that they get this from the token endpoint.

The initial access token isn't even in play here.

  -- Justin

On 06/06/2013 01:49 PM, Phil Hunt wrote:
>>>> ... because it already *is* a REST protected API. It's protected 
>>>> with the Registration Access Token. Which is an OAuth 2.0 Bearer 
>>>> token.
>>>>
>>>> The *only* difference is how you get the token, which has nothing 
>>>> to do with the REST protected API that it's protecting.
>>>>
>>>>  -- Justin
>>>>
>>>>>>>>> FWIW, I just read the spec through with fresh eyes, and I 
>>>>>>>>> found the explanation of the workflow in 1.4.2 very useful.
>>>>>>>>>
>>>>>>>>> The first part, where the developer registers & gets a token 
>>>>>>>>> for a scope, is vanilla OAuth 2. (right?)
>>>>>>>>
>>>>>>>> someone) getting a token through some other means, like 
>>>>>>>> browsing to a developer portal and getting a Bearer token. I've 
>>>>>>>> edited the example in 1.4.3 in the latest (unpublished) text so 
>>>>>>>> that the developer is literally doing OAuth2 to get the initial 
>>>>>>>> token. It's important to note that this could be any flavor of 
>>>>>>>> OAuth2 token, though Bearer tokens are of course the most common.
>>>>>>>>
>>>>>>>> endpoint for this, but couldn't come up with a reasonable way 
>>>>>>>> of doing so (as has been discussed on the list.
>>>>>>>
>>>>>>> *Use the normal token issuing process.*  One reason given was 
>>>>>>> what about anonymous clients?  The answer is, they don't have to 
>>>>>>> do anything. Remember that you have defined TWO endpoints.  The 
>>>>>>> access at the "registration endpoint".  Clients wanting to 
>>>>>>> update their profiles do the normal client token request flow to 
>>>>>>> the token endpoint to obtain a normal access token useable at 
>>>>>>> the "configuration endpoint".
>>>>>>>
>>>>>>
>>>>>> save the client secret but know to only use it at the 
>>>>>> registration endpoint, and not the token endpoint where they're 
>>>>>> used to. This way, it's clear. You get a token that you use at a 
>>>>>> given endpoint, the end.
>>>>>>
>>>>>> want to, or have them expire, if you want to limit the lifespan 
>>>>>> of your clients. It's only the security considerations section 
>>>>>> that suggests against expiring the tokens, and for good reason. 
>>>>>> But it's your choice to change that if you don't want 
>>>>>> longstanding read/edit access to a client's configuration.
>>>>>>
>>>>>>> 2.  No need to have a special token issuing method. Creating a 
>>>>>>> new issuing process suggests that the WG can't drink its own 
>>>>>>> koolaid.  Because at the first seeming challenge, the WG create 
>>>>>>> a new flow. How do we expect implementers to behave?
>>>>>>
>>>>>> stretch your analogy. Bearer tokens were, which is also the 
>>>>>> group's koolaid. We tried to go down the road you suggest and it 
>>>>>> was a dead end. Why do you think it will work better this time? 
>>>>>> And I'd like to point out a decision from several years ago now 
>>>>>> to separate the notion of "how you get a token" from "how you use 
>>>>>> a token" in OAuth2. OAuth1 had all of these rolled in together, 
>>>>>> and deployment experience showed us that people didn't really 
>>>>>> want to use it that way. People want components that make sense 
>>>>>> on their own that let you build systems like this that also make 
>>>>>> sense.
>>>>>>
>>>>>> your tokens from, just that you have them, so from that 
>>>>>> perspective it is just a protected resource. Our implementation 
>>>>>> here literally just looks for the token on the way in in the auth 
>>>>>> layer and makes sure it's got a special service-specific scope 
>>>>>> that handles registration.
>>>>>>
>>>>>>>
>>>>>>> If the draft drops "registration access tokens", a lot of the 
>>>>>>> text in the draft disappears.  The whole spec is much simpler.
>>>>>>
>>>>>> And honestly, not much of the text actually goes away. Most of 
>>>>>> the draft isn't about dealing with the registration access token, 
>>>>>> it's about dealing with the client metadata and the RESTful 
>>>>>> protocol for managing that. The registration access token is a 
>>>>>> mechanism for doing so.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> And I’m not sure 1.4.3 adds any value at all.  It just seems 
>>>>>>>>> to be a matter of different ways you could get and make use of 
>>>>>>>>> the registration access token; and I'm sure there are various 
>>>>>>>> Initial Access Token different (the developer now uses OAuth2 
>>>>>>>> to configure their build environment). The *real* important 
>>>>>>>> doesn't call the registration endpoint, the developer (and 
>>>>>>>> their build environment) does. So yes, it's exactly all about 
>>>>>>>> how you get and use the registration access token. There are 
>>>>>>>> plenty of other ways to do it as well, so that's why this 
>>>>>>>> section was a non-normative set of examples. To facilitate that 
>>>>>>>> understanding, I've moved it to an appendix in the working copy 
>>>>>>>> of draft -12.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>>  -T
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     following the proposed drafts until the last call he is
>>>>>>>>>     now raising an issue no one in the WG saw as an issue.
>>>>>>>>>     That’s not to say his point isn’t valid, but the
>>>>>>>>>     discussion continues to go all over the map between
>>>>>>>>>     “local” and “federated” tokens, usage of the RFC6749
>>>>>>>>>     without the threads becoming so convoluted no one is able
>>>>>>>>>     to make sense or even comprehend the point being discussed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     token as the Registration Access Token, it's just not
>>>>>>>>>     coming from a Token Endpoint. However, since an OAuth
>>>>>>>>>     Protected Resource doesn't care where its tokens come from
>>>>>>>>>     so long as it can validate them, I don't see this as a
>>>>>>>>>     problem -- this is a key point where Phil and I disagree.
>>>>>>>>>
>>>>>>>>>     [DFC]  I understand the disagreement, but I have not seen
>>>>>>>>>     a proposal from Phil that would describe the differences
>>>>>>>>>     owner protected data and the registration structure, which
>>>>>>>>>     I do not agree with. As I said in the previous
>>>>>>>>>     response, my users do NOT want to provide implied access
>>>>>>>>>     to resource owner protected data just because a client is
>>>>>>>>>     situation if the client credential flow is used to
>>>>>>>>>     register an application. Since our
>>>>>>>>>     implementation does NOT support the implicit flow, that
>>>>>>>>>     use case is one we have elected NOT to support.
>>>>>>>>>
>>>>>>>>>     [DFC]  I repeat my initial comment, this conversation has
>>>>>>>>>     been a circular exchange now for the past few days without
>>>>>>>>>         with scope registration everything is clear as it is
>>>>>>>>>         for any other protected API. Draft 11 invents a whole
>>>>>>>>>         new system. I strongly disagree with this.
>>>>>>>>>
>>>>>>>>>         Phil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             FWIW I believe that is a significantly strong
>>>>>>>>>             reason to differentiate an access token that can
>>>>>>>>>             access the registration information without having
>>>>>>>>>             the ability to access protected data. Especially
>>>>>>>>>             given the implied strength of the “client
>>>>>>>>>             credential” obtained access token. I have found it
>>>>>>>>>             extremely confusing to users when explaining the
>>>>>>>>>             difference between an access token obtained
>>>>>>>>>             credential flow, simply because they are both
>>>>>>>>>             called an “access token”. Changing the meaning of
>>>>>>>>>             an access token obtained through the client
>>>>>>>>>             credential flow to mean it has the ability to
>>>>>>>>>             to have access to protected data will only
>>>>>>>>>             increase both the complexity of the access tokens
>>>>>>>>>             as well as make their usage harder to explain to
>>>>>>>>>             non-technical individuals who have to understand
>>>>>>>>>             the differences between the access tokens obtained
>>>>>>>>>             through the various flows.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             Just my two cents.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             Best regards,
>>>>>>>>>
>>>>>>>>>             Don
>>>>>>>>>
>>>>>>>>>             Donald F. Coffin
>>>>>>>>>
>>>>>>>>>             Founder/CTO
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             REMI Networks
>>>>>>>>>
>>>>>>>>>             would never allow in current form. Yes it gives
>>>>>>>>>             each execution instance a new id, but that isnt
>>>>>>>>>             what sp's want. It is a huge attack and management
>>>>>>>>>                 I'm not willing to write out an entire class
>>>>>>>>>                 of clients from this spec, especially when we
>>>>>>>>>                 have stated use cases for them doing dynamic
>>>>>>>>>                 registration.
>>>>>>>>>
>>>>>>>>>                         the created resource (IE: the
>>>>>>>>>                         Registration Access Token)? You can't
>>>>>>>>>                         use the client_credentials flow for a
>>>>>>>>>                         client with no credentials!
>>>>>>>>>
>>>>>>>>>                          -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 circles, since I just was
>>>>>>>>>                                 going to bring up my counter
>>>>>>>>>                                 argument of "what about
>>>>>>>>>                                 clients with no credentials?"
>>>>>>>>>                                 again, which *still* isn't
>>>>>>>>>                                 addressed by what you suggest
>>>>>>>>>                                 doing, below. I also believe
>>>>>>>>>                                 that getting rid of the
>>>>>>>>>                                 to write one. And the fact
>>>>>>>>>                                 that OIDC is doing it this
>>>>>>>>>                                 way, and considered but
>>>>>>>>>                                 describing, should say
>>>>>>>>>                                 whether or not this is the
>>>>>>>>>                                 Regardless, I agree to park
>>>>>>>>>                                 this issue and leave the text
>>>>>>>>>                                 as is. We'll move to the next
>>>>>>>>>                                 draft in the last call process
>>>>>>>>>                                 shortly, as I have a handful
>>>>>>>>>                                 of non-normative editorial
>>>>>>>>>                                 changes that I need to make,
>>>>>>>>>                                 thanks to feedback from a few
>>>>>>>>>                                 folks.
>>>>>>>>>
>>>>>>>>>                                 Again, thanks for your
>>>>>>>>>                                 thorough review, Phil, and I
>>>>>>>>>                                 look forward to future feedback.
>>>>>>>>>
>>>>>>>>>                                  -- Justin
>>>>>>>>>
>>>>>>>>>                                     There is absolutely no
>>>>>>>>>                                     need for a registration
>>>>>>>>>                                     access token.
>>>>>>>>>                                     If you can't follow 6749
>>>>>>>>>                                     and need new issuing
>>>>>>>>>                                     methods, what are others
>>>>>>>>>                                     to say regarding inventing
>>>>>>>>>                                     new methods?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     I have not heard a good
>>>>>>>>>                                     reason for the special
>>>>>>>>>                                     to warrant a new method
>>>>>>>>>                                     for issuing an access
>>>>>>>>>                                     token. Does the broader
>>>>>>>>>                                     group realize this is what
>>>>>>>>>                                     the spec says?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     that is a political
>>>>>>>>>                                     reason, not a technical
>>>>>>>>>                                     reason. Still,
>>>>>>>>>                                     strong objective.  Even
>>>>>>>>>                                     so, oidc could keep using
>>>>>>>>>                                     their method just fine.
>>>>>>>>>                                     There is no obligation
>>>>>>>>>                                     here to do the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     expiry? It makes no sense
>>>>>>>>>                                     to have another token with
>>>>>>>>>                                     longer expiry. B'sides,
>>>>>>>>>                                     even expired the client
>>>>>>>>>                                     can re-register from scratch.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     Why force the client to
>>>>>>>>>                                     persist multiple tokens
>>>>>>>>>                                     and creds? That is far far
>>>>>>>>>                                     too complex.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     Apologies for my rant.
>>>>>>>>>                                     Maybe we should park this
>>>>>>>>>                                     for now. We are going in
>>>>>>>>>                                     circles.
>>>>>>>>>
>>>>>>>>>                                     Phil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     On 2013-05-31, at 11:25,
>>>>>>>>>                                     Justin Richer
>>>>>>>>>                                     <[email-masked]
>>>>>>>>>                                         straight just fine,
>>>>>>>>>                                         but I just need you to
>>>>>>>>>                                         be clear about which
>>>>>>>>>                                         part you're objecting
>>>>>>>>>                                         to because the answers
>>>>>>>>>                                         are different. Please
>>>>>>>>>                                         use the terms as
>>>>>>>>>                                         defined in the
>>>>>>>>>                                         document so that we
>>>>>>>>>                                         all know which
>>>>>>>>>                                         component we're
>>>>>>>>>                                         talking about. I'm
>>>>>>>>>                                         sure you'd agree than
>>>>>>>>>                                         in specification work
>>>>>>>>>                                         such as this,
>>>>>>>>>                                         precision of language
>>>>>>>>>                                         parties. This is
>>>>>>>>>                                         precisely why there's
>>>>>>>>>                                         a Terminology section
>>>>>>>>>                                         right up front, so
>>>>>>>>>                                         Token" you can know
>>>>>>>>>                                         that I mean a very
>>>>>>>>>                                         specific thing, and
>>>>>>>>>                                         asking you, please,
>>>>>>>>>                                         use the defined terms
>>>>>>>>>                                         so that we can avoid
>>>>>>>>>                                         But anyway, what
>>>>>>>>>                                         you're talking about
>>>>>>>>>                                         below, "the token the
>>>>>>>>>                                         client uses to update
>>>>>>>>>                                         is profile" *IS* the
>>>>>>>>>                                         that token is used
>>>>>>>>>                                         for. You're not asking
>>>>>>>>>                                         for it to go away,
>>>>>>>>>                                         you're asking for it
>>>>>>>>>                                         to come from the Token
>>>>>>>>>                                         Endpoint instead of
>>>>>>>>>                                         Registration Endpoint.
>>>>>>>>>                                         I don't see how the
>>>>>>>>>                                         client *can* get it
>>>>>>>>>                                         from the normal token
>>>>>>>>>                                         process without
>>>>>>>>>                                         jumping through
>>>>>>>>>                                         specialized hoops to
>>>>>>>>>                                         make that happen. I've
>>>>>>>>>                                         implemented the draft
>>>>>>>>>                                         the way that it is
>>>>>>>>>                                         right now, both client
>>>>>>>>>                                         and server side, and
>>>>>>>>>                                         it works. Others have
>>>>>>>>>                                         implemented it, too.
>>>>>>>>>                                         This is a proven
>>>>>>>>>                                         pattern and from where
>>>>>>>>>                                         I sit there is both
>>>>>>>>>                                         rough consensus and
>>>>>>>>>                                         running code.
>>>>>>>>>                                         already pointed out
>>>>>>>>>                                         how the solutions
>>>>>>>>>                                         you've proposed so far
>>>>>>>>>                                         won't work in
>>>>>>>>>                                         practice, for various
>>>>>>>>>                                         have already been
>>>>>>>>>                                         brought up and
>>>>>>>>>                                         discussed previously.
>>>>>>>>>                                         If you have another
>>>>>>>>>                                         way for the client to
>>>>>>>>>                                         get its Registration
>>>>>>>>>                                         propose it; but I
>>>>>>>>>                                         haven't seen anything
>>>>>>>>>                                         yet that will fly.
>>>>>>>>>                                             objection! We
>>>>>>>>>                                             can't keep it
>>>>>>>>>                                             straight. Their
>>>>>>>>>                                             should be no such
>>>>>>>>>                                             thing as a
>>>>>>>>>                                              Just the token
>>>>>>>>>                                             the client obtains
>>>>>>>>>                                             to update its
>>>>>>>>>                                             profile through
>>>>>>>>>                                             10:55, Justin
>>>>>>>>>                                                 Which token
>>>>>>>>>                                                 are you
>>>>>>>>>                                                 referring to here?
>>>>>>>>>                                                 Token, then
>>>>>>>>>                                                 you could get
>>>>>>>>>                                                 that through
>>>>>>>>>                                                 no problem.
>>>>>>>>>                                                 (The lifecycle
>>>>>>>>>                                                 explicitly but
>>>>>>>>>                                                 I would be
>>>>>>>>>                                                 willing to do
>>>>>>>>>                                                 so.) Or you
>>>>>>>>>                                                 Doesn't
>>>>>>>>>                                                 matter, just
>>>>>>>>>                                                 like it
>>>>>>>>>                                                 then having
>>>>>>>>>                                                 the token come
>>>>>>>>>                                                 from the token
>>>>>>>>>                                                 clients
>>>>>>>>>                                                 getting
>>>>>>>>>                                                 or with
>>>>>>>>>                                                 granting
>>>>>>>>>                                                 it. Plus it
>>>>>>>>>                                                 adds extra
>>>>>>>>>                                                 round trips
>>>>>>>>>                                                 which don't
>>>>>>>>>                                                     server
>>>>>>>>>                                                     rather
>>>>>>>>>                                                     then by
>>>>>>>>>                                                     draft it
>>>>>>>>>                                                     is
>>>>>>>>>                                                     process
>>>>>>>>>                                                     outlive
>>>>>>>>>                                                     19:47,
>>>>>>>>>                                                         don't
>>>>>>>>>                                                         below
>>>>>>>>>                                                         -- it
>>>>>>>>>                                                         an
>>>>>>>>>                                                         special handling.
>>>>>>>>>                                                         totally doesn't
>>>>>>>>>                                                         used
>>>>>>>>>                                                         to
>>>>>>>>>                                                         else
>>>>>>>>>                                                         is out
>>>>>>>>>                                                         ways
>>>>>>>>>                                                         *could* use
>>>>>>>>>                                                         it and
>>>>>>>>>                                                         You
>>>>>>>>>                                                         seem
>>>>>>>>>                                                             by
>>>>>>>>>                                                             5:25
>>>>>>>>>                                                             PM
>>>>>>>>>                                                             Re: [OAUTH-WG]
>>>>>>>>>                                                             PM, Justin
>>>>>>>>>                                                             the scenario
>>>>>>>>>                                                             you describe,
>>>>>>>>>                                                             you trade
>>>>>>>>>                                                             are federated
>>>>>>>>>                                                             the PR.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:50:48 -0700

We have two separate discussions going on.  8-)

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

> I thought we were talking about the registration access token, not the initial access token?
> 
>  -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 10:51:56 -0700

When they are issued their client credential after successfully registering….isn't that the whole point of the process?

Once they register, they are no longer public.  After that, they just get a token like everyone else.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-06-06, at 10:49 AM, Justin Richer wrote:

> Then how do they get their equivalent of a registration access token to manage their configurations? 
> 
> The draft proposes that they get this token right from the registration endpoint. You're proposing that they get this from the token endpoint.
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:54:34 -0400

... My bad, you're right. I was getting my wires crossed with all these 
emails.

In my view, the initial access token is, fundamentally, an access token 
used to constrain access to the registration endpoint (not the 
configuration endpoint, and not to get "normal" access tokens). Just 
like a normal OAuth token is an opaque token used to constrain access to 
the protected resource. If you want to define anything more for either 
of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it 
goes beyond registration. And if registration is silent on all of this, 
and just says "the registration endpoint may be an OAuth 2.0 protected 
resource", then whatever interoperable solutions we can come up with for 
validating a cross-domain token can be applied here. I don't think it 
makes sense to constrain registration before the rest of this work is 
baked.

  -- Justin

On 06/06/2013 01:50 PM, Phil Hunt wrote:
>>> Therefore, in this case, I do not believe that defining access 
>>> tokens in the broader sense makes this issue clearer.
>>>
>>>> optional), then you're locked to whatever process you want to use 
>>>> to verify/validate that token. Since it's just an OAuth token, 
>>>> you've got a number of things that you can do (assertions, 
>>>> introspection, magic).
>>>>
>>>>>> Phil, as I and several others have explained previously, that's 
>>>>>> not true at all. It's a token that gives authorization to the 
>>>>>> registration endpoint. The fact that you can use it as an 
>>>>>> assertion to pass along signed claims is an artifact of it being 
>>>>>> an OAuth token and an OAuth token is an opaque string. Please 
>>>>>> read through the dynamic registration draft again -- it says 
>>>>>> absolutely nothing about assertions, signatures, or claims with 
>>>>>> regard to this token.
>>>>> It depends which case you are using.  If the developer is talking 
>>>>> to a single deployment domain and obtains an initial access token 
>>>>> and then ships it with all clients, then sure.  In this scenario, 
>>>>> the contents are totally controlled by the local domain.
>>>>>
>>>>> environment is siloed.  But then, if this is your case, I'm not 
>>>>> sure why this draft is at the IETF.
>>>>>
>>>>> assertion and the deployment domain has to decide to accept it. 
>>>>>  So you are a developer and you want to build a client for a 
>>>>> Microsoft or Oracle app.  You want to be able to ship that to your 
>>>>> customers. You register with the appropriate publisher and they 
>>>>> give you a signed assertion that can be used as the "Initial 
>>>>> Access Token".    This token is then accepted by the deployment 
>>>>> domain and then it decides if it trusts the signer or not.
>>>>>
>>>>> ===> For this to work, the contents and format of that token MUST 
>>>>> be defined.   Otherwise how could we ensure a Microsoft signed 
>>>>> assertion would be accepted by a PingIdentity OAuth server?  Or 
>>>>> any other combination of implementations from different 
>>>>> vendors/communities?
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Bearer or not bearer is a distraction. The fact that the 
>>>>>>> contents and format of this token is out of scope leaves a HUGE 
>>>>>>> interop gap.
>>>>>>
>>>>>> defining this stuff, but as a separate and complementary spec 
>>>>>> from registration.
>>>>>
>>>>>> client secrets (using jwks_uri to register public keys), I have 
>>>>>> to empirically disagree with that statement.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>> requires a registered client that may need to be registered to 
>>>>>>>> do the registration.
>>>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - 
>>>>>>>> FI/Espoo)" <[email-masked] 
>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>> widely implemented and the registration flow as documented 
>>>>>>>>> seems like it should work?  -T
>>>>>>>>> That’s the answer for why there is support for bearer tokens 
>>>>>>>>> but it is not the answer to why that’s the only supported 
>>>>>>>>> mechanism.

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 13:56:13 -0400

Before they register, they're neither public nor private. After they 
register, they're either public or private depending on if they want 
to/can use a client secret or equivalent to talk to the token endpoint.

Also, having a client register and allowing it to get a token through 
the client_credentials flow (without a user in the loop) is potentially 
dangerous unless things are very carefully scope-limited anyway.

  -- Justin

On 06/06/2013 01:51 PM, Phil Hunt wrote:
> When they are issued their client credential after successfully 
> registering….isn't that the whole point of the process?
>
>> The draft proposes that they get this token right from the 
>> registration endpoint. You're proposing that they get this from the 
>> token endpoint.
>>
>>>>> This means the configuration endpoints can use normal access 
>>>>> tokens obtained through RFC6749 section 4.4 (Client Auth) flows.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>>>>>>>> - you use that “Initial token” token to register, in 
>>>>>>>>>>> exchange you get the client-id & so on, and also a a 
>>>>>>>>>>> per-registration “Registration token” for updating that 
>>>>>>>>>>> particular registration information
>>>>>>>>>> browsing to a developer portal and getting a Bearer token. 
>>>>>>>>>> I've edited the example in 1.4.3 in the latest (unpublished) 
>>>>>>>>>> text so that the developer is literally doing OAuth2 to get 
>>>>>>>>>> the initial token. It's important to note that this could be 
>>>>>>>>>> any flavor of OAuth2 token, though Bearer tokens are of 
>>>>>>>>>> course the most common.
>>>>>>>>>>
>>>>>>>>>> Right, it's a new way to get a bearer token so that you can 
>>>>>>>>>> use it at the protected resource. We wanted to re-use the 
>>>>>>>>>> token endpoint for this, but couldn't come up with a 
>>>>>>>>>> reasonable way of doing so (as has been discussed on the list.
>>>>>>>>>
>>>>>>>>> what about anonymous clients?  The answer is, they don't have 
>>>>>>>>> to do anything. Remember that you have defined TWO endpoints. 
>>>>>>>>>  The "registration endpoint" and the "configuration endpoint". 
>>>>>>>>>  A server accepting anonymous registration simply accepts 
>>>>>>>>> anonymous access at the "registration endpoint".  Clients 
>>>>>>>>> wanting to update their profiles do the normal client token 
>>>>>>>>> request flow to the token endpoint to obtain a normal access 
>>>>>>>>> token useable at the "configuration endpoint".
>>>>>>>>>
>>>>>>>>
>>>>>>>> client_credentials as a flow to only a special 
>>>>>>>> (service-specific) scope for client configuration purposes. 
>>>>>>>> This, I think, is much more complicated to implement and much 
>>>>>>>> more error prone. I don't think it's even possible in the 
>>>>>>>> software stack we're building on top of. And furthermore, 
>>>>>>>> you're not letting public clients dynamically register anymore, 
>>>>>>>> since you'd be forcing everyone to have a client secret. Your 
>>>>>>>> dynamic public clients would have to save the client secret but 
>>>>>>>> know to only use it at the registration endpoint, and not the 
>>>>>>>> token endpoint where they're used to. This way, it's clear. You 
>>>>>>>>> needed for minutes since it will likely only be used to read 
>>>>>>>>> or update profiles or to perform client initiated credential 
>>>>>>>>> rotation.
>>>>>>>>
>>>>>>>> [JR] You *can* throw away your registration access tokens if 
>>>>>>>> you want to, or have them expire, if you want to limit the 
>>>>>>>> lifespan of your clients. It's only the security considerations 
>>>>>>>> section that suggests against expiring the tokens, and for good 
>>>>>>>> reason. But it's your choice to change that if you don't want 
>>>>>>>>> koolaid.  Because at the first seeming challenge, the WG 
>>>>>>>>> create a new flow. How do we expect implementers to behave?
>>>>>>>>
>>>>>>>> group's koolaid. We tried to go down the road you suggest and 
>>>>>>>> it was a dead end. Why do you think it will work better this 
>>>>>>>> time? And I'd like to point out a decision from several years 
>>>>>>>> ago now to separate the notion of "how you get a token" from 
>>>>>>>> "how you use a token" in OAuth2. OAuth1 had all of these rolled 
>>>>>>>> in together, and deployment experience showed us that people 
>>>>>>>> didn't really want to use it that way. People want components 
>>>>>>>> that make sense on their own that let you build systems like 
>>>>>>>> this that also make sense.
>>>>>>>>
>>>>>>>> [JR] It already is. Protected resources don't care where you 
>>>>>>>> get your tokens from, just that you have them, so from that 
>>>>>>>> here literally just looks for the token on the way in in the 
>>>>>>>> auth layer and makes sure it's got a special service-specific 
>>>>>>>> scope that handles registration.
>>>>>>>>
>>>>>>>>>
>>>>>>>> [JR] Much simpler, perhaps, but much less functional and 
>>>>>>>> useful. And honestly, not much of the text actually goes away. 
>>>>>>>> Most of the draft isn't about dealing with the registration 
>>>>>>>> access token, it's about dealing with the client metadata and 
>>>>>>>> the RESTful protocol for managing that. The registration access 
>>>>>>>> token is a mechanism for doing so.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>   From an OAuth 2 point of view, there's nothing special 
>>>>>>>>>>> about how you get or use the Initial token, but giving it a 
>>>>>>>>>>> special name makes explaining a plausible workflow easier.
>>>>>>>>>>
>>>>>>>>>>> Having said that, I have trouble imagining the scenario 
>>>>>>>>>>> where you'd use the 1.4.1 flow, but that may be because of 
>>>>>>>>>>> my Google-centric worldview.
>>>>>>>>>>
>>>>>>>>>> need to handle this flow as well. This is the client acting 
>>>>>>>>>> on its own behalf, showing up and saying "hi, I'm a client!" 
>>>>>>>>>> and that's that. I think this is a very important case for 
>>>>>>>>>>> to be a matter of different ways you could get and make use 
>>>>>>>>>>> of the registration access token; and I'm sure there are 
>>>>>>>>>>> various interesting combinations that haven't been thought 
>>>>>>>>>>> of there.  I'd just lose 1.4.3.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> current working text is make the initial process of getting 
>>>>>>>>>> the Initial Access Token different (the developer now uses 
>>>>>>>>>> OAuth2 to configure their build environment). The *real* 
>>>>>>>>>> important difference that's being shown here, though, is that 
>>>>>>>>>> the client doesn't call the registration endpoint, the 
>>>>>>>>>> developer (and their build environment) does. So yes, it's 
>>>>>>>>>> exactly all about how you get and use the registration access 
>>>>>>>>>> token. There are plenty of other ways to do it as well, so 
>>>>>>>>>> that's why this section was a non-normative set of examples. 
>>>>>>>>>> To facilitate that understanding, I've moved it to an 
>>>>>>>>>> appendix in the working copy of draft -12.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>>>  -T
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       * To be clear, Draft 11 has the same Registration
>>>>>>>>>>>     Access Token system that has been in place since draft
>>>>>>>>>>>     01, it is not inventing something new at the last minute
>>>>>>>>>>>     as could be inferred from the statement below.
>>>>>>>>>>>
>>>>>>>>>>>     [DFC]  I agree with Justin.  There is nothing new in
>>>>>>>>>>>     draft 11 regarding Registration Access Tokens that
>>>>>>>>>>>     wasn’t in the initial draft.  It appears because Phil
>>>>>>>>>>>     hasn’t been following the proposed drafts until the last
>>>>>>>>>>>     call he is now raising an issue no one in the WG saw as
>>>>>>>>>>>     an issue. That’s not to say his point isn’t valid, but
>>>>>>>>>>>     the discussion continues to go all over the map between
>>>>>>>>>>>     “Token” endpoint, etc.  It would be great if all of
>>>>>>>>>>>     without the threads becoming so convoluted no one is
>>>>>>>>>>>     able to make sense or even comprehend the point being
>>>>>>>>>>>     discussed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       * DynReg is using an absolutely standard OAuth 2
>>>>>>>>>>>     Bearer token as the Registration Access Token, it's just
>>>>>>>>>>>     not coming from a Token Endpoint. However, since an
>>>>>>>>>>>     OAuth Protected Resource doesn't care where its tokens
>>>>>>>>>>>     come from so long as it can validate them, I don't see
>>>>>>>>>>>     this as a problem -- this is a key point where Phil and
>>>>>>>>>>>     I disagree.
>>>>>>>>>>>
>>>>>>>>>>>     [DFC]  I understand the disagreement, but I have not
>>>>>>>>>>>     seen a proposal from Phil that would describe the
>>>>>>>>>>>     differences between the two perspectives other than to
>>>>>>>>>>>     say that the Dynamic Registration should use the Token
>>>>>>>>>>>     endpoint defined in RFC6749, which does not discuss
>>>>>>>>>>>     dynamic registration. Phil’s point as I understand it is
>>>>>>>>>>>     that there should be no difference between an access
>>>>>>>>>>>     token used to access resource owner protected data and
>>>>>>>>>>>     the registration structure, which I do not agree with.
>>>>>>>>>>>     As I said in the previous
>>>>>>>>>>>     to resource owner protected data just because a client
>>>>>>>>>>>     has been a circular exchange now for the past few days
>>>>>>>>>>>     without any appearance of an alternative option to
>>>>>>>>>>>     resolve the issues.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      -- Justin
>>>>>>>>>>>
>>>>>>>>>>>         registration acces token issues by normal token
>>>>>>>>>>>         server with scope registration everything is clear
>>>>>>>>>>>         as it is for any other protected API. Draft 11
>>>>>>>>>>>         invents a whole new system. I strongly disagree with
>>>>>>>>>>>         this.
>>>>>>>>>>>
>>>>>>>>>>>         Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>             access the registration information without
>>>>>>>>>>>             having the ability to access protected data.
>>>>>>>>>>>             Especially given the implied strength of the
>>>>>>>>>>>             “client credential” obtained access token. I
>>>>>>>>>>>             have found it extremely confusing to users when
>>>>>>>>>>>             explaining the difference between an access
>>>>>>>>>>>             token obtained thorough an authorization code
>>>>>>>>>>>             flow and a client credential flow, simply
>>>>>>>>>>>             because they are both called an “access token”.
>>>>>>>>>>>             Changing the meaning of an access token obtained
>>>>>>>>>>>             through the client credential flow to mean it
>>>>>>>>>>>             has the ability to update a registration, when a
>>>>>>>>>>>             user may not want it to have access to protected
>>>>>>>>>>>             data will only increase both the complexity of
>>>>>>>>>>>             the access tokens as well as make their usage
>>>>>>>>>>>             harder to explain to non-technical individuals
>>>>>>>>>>>             who have to understand the differences between
>>>>>>>>>>>             what sp's want. It is a huge attack and
>>>>>>>>>>>             management headache. Eliminate or propose a
>>>>>>>>>>>             different solution.
>>>>>>>>>>>
>>>>>>>>>>>             Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 of clients from this spec, especially when
>>>>>>>>>>>                 we have stated use cases for them doing
>>>>>>>>>>>                 dynamic registration.
>>>>>>>>>>>
>>>>>>>>>>>                     Well the only client that wouldn't have
>>>>>>>>>>>                     a credential is an implicit client. An
>>>>>>>>>>>                     implicit client is transient and so
>>>>>>>>>>>                     would never update.
>>>>>>>>>>>
>>>>>>>>>>>                         But the outstanding question is: how
>>>>>>>>>>>                         do you get the access token to
>>>>>>>>>>>                         access the created resource (IE: the
>>>>>>>>>>>                         Registration Access Token)? You
>>>>>>>>>>>                         can't use the client_credentials
>>>>>>>>>>>                             Yes. I specified the trivial
>>>>>>>>>>>                             solution to anonymous clients
>>>>>>>>>>>                             earlier.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                 clients with no
>>>>>>>>>>>                                 *still* isn't addressed by
>>>>>>>>>>>                                 what you suggest doing,
>>>>>>>>>>>                                 below. I also believe that
>>>>>>>>>>>                                 getting rid of the
>>>>>>>>>>>                                 Registration Access Token
>>>>>>>>>>>                                 but using some other token
>>>>>>>>>>>                                 method would actually make
>>>>>>>>>>>                                 the spec larger, though I'd
>>>>>>>>>>>                                 be glad to review a concrete
>>>>>>>>>>>                                 counter-proposal if you'd
>>>>>>>>>>>                                 like to write one. And the
>>>>>>>>>>>                                 fact that OIDC is doing it
>>>>>>>>>>>                                 something to the WG here
>>>>>>>>>>>                                 about whether or not this is
>>>>>>>>>>>                                 the right choice. Rough
>>>>>>>>>>>                                 consensus and running code,
>>>>>>>>>>>                                 after all.
>>>>>>>>>>>
>>>>>>>>>>>                                 this issue and leave the
>>>>>>>>>>>                                 text as is. We'll move to
>>>>>>>>>>>                                 the next draft in the last
>>>>>>>>>>>                                 call process shortly, as I
>>>>>>>>>>>                                 have a handful of
>>>>>>>>>>>                                 non-normative editorial
>>>>>>>>>>>                                 thanks to feedback from a
>>>>>>>>>>>                                 few folks.
>>>>>>>>>>>
>>>>>>>>>>>                                 Again, thanks for your
>>>>>>>>>>>                                     Get rid of it and just
>>>>>>>>>>>                                     use access tokens as per
>>>>>>>>>>>                                     6749. If you can't
>>>>>>>>>>>                                     follow 6749 and need new
>>>>>>>>>>>                                     issuing methods, what
>>>>>>>>>>>                                     are others to say
>>>>>>>>>>>                                     process or one good
>>>>>>>>>>>                                     enough to warrant a new
>>>>>>>>>>>                                     method for issuing an
>>>>>>>>>>>                                     access token. Does the
>>>>>>>>>>>                                     broader group realize
>>>>>>>>>>>                                     this is what the spec says?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     Yes, i heard a lot
>>>>>>>>>>>                                     saying OIDC does it this
>>>>>>>>>>>                                     way. But that is a
>>>>>>>>>>>                                     political reason, not a
>>>>>>>>>>>                                     technical reason. Still,
>>>>>>>>>>>                                     compatibility is always
>>>>>>>>>>>                                     a strong objective.
>>>>>>>>>>>                                      Even so, oidc could
>>>>>>>>>>>                                     keep using their method
>>>>>>>>>>>                                     just fine. There is no
>>>>>>>>>>>                                     obligation here to do
>>>>>>>>>>>                                     the same.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     The only reason so far
>>>>>>>>>>>                                     was expiry of client
>>>>>>>>>>>                                     creds. Well, why not
>>>>>>>>>>>                                     require the client to
>>>>>>>>>>>                                     update prior to expiry?
>>>>>>>>>>>                                     It makes no sense to
>>>>>>>>>>>                                     have another token with
>>>>>>>>>>>                                     longer expiry. B'sides,
>>>>>>>>>>>                                     even expired the client
>>>>>>>>>>>                                     can re-register from
>>>>>>>>>>>                                     scratch.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     Why force the client to
>>>>>>>>>>>                                     persist multiple tokens
>>>>>>>>>>>                                     and creds? That is far
>>>>>>>>>>>                                     far too complex.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     Finally if you get rid
>>>>>>>>>>>                                     of registration access
>>>>>>>>>>>                                     token the spec size will
>>>>>>>>>>>                                     drop roughly in half
>>>>>>>>>>>                                     IMO. This suggests
>>>>>>>>>>>                                     simplicity to me.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     Apologies for my rant.
>>>>>>>>>>>                                     Maybe we should park
>>>>>>>>>>>                                     this for now. We are
>>>>>>>>>>>                                     going in circles.
>>>>>>>>>>>
>>>>>>>>>>>                                     Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                                     On 2013-05-31, at 11:25,
>>>>>>>>>>>                                     Justin Richer
>>>>>>>>>>>                                     <[email-masked]
>>>>>>>>>>>                                         but I just need you
>>>>>>>>>>>                                         to be clear about
>>>>>>>>>>>                                         objecting to because
>>>>>>>>>>>                                         the answers are
>>>>>>>>>>>                                         different. Please
>>>>>>>>>>>                                         sure you'd agree
>>>>>>>>>>>                                         than in
>>>>>>>>>>>                                         specification work
>>>>>>>>>>>                                         precision of
>>>>>>>>>>>                                         language and labels
>>>>>>>>>>>                                         is key for
>>>>>>>>>>>                                         This is precisely
>>>>>>>>>>>                                         why there's a
>>>>>>>>>>>                                         Registration Token"
>>>>>>>>>>>                                         I mean a very
>>>>>>>>>>>                                         different specific
>>>>>>>>>>>                                         thing. So I'm asking
>>>>>>>>>>>                                         you, please, use the
>>>>>>>>>>>                                         defined terms so
>>>>>>>>>>>                                         that we can avoid
>>>>>>>>>>>                                         below, "the token
>>>>>>>>>>>                                         the client uses to
>>>>>>>>>>>                                         Token. That's all
>>>>>>>>>>>                                         that that token is
>>>>>>>>>>>                                         used for. You're not
>>>>>>>>>>>                                         asking for it to go
>>>>>>>>>>>                                         away, you're asking
>>>>>>>>>>>                                         for it to come from
>>>>>>>>>>>                                         the Token Endpoint
>>>>>>>>>>>                                         instead of the
>>>>>>>>>>>                                         Endpoint. I don't
>>>>>>>>>>>                                         see how the client
>>>>>>>>>>>                                         *can* get it from
>>>>>>>>>>>                                         make that happen.
>>>>>>>>>>>                                         I've implemented the
>>>>>>>>>>>                                         draft the way that
>>>>>>>>>>>                                         it is right now,
>>>>>>>>>>>                                         both client and
>>>>>>>>>>>                                         server side, and it
>>>>>>>>>>>                                         works. Others have
>>>>>>>>>>>                                         testing, and it
>>>>>>>>>>>                                         works. This is a
>>>>>>>>>>>                                         proven pattern and
>>>>>>>>>>>                                         from where I sit
>>>>>>>>>>>                                         you've proposed so
>>>>>>>>>>>                                         far won't work in
>>>>>>>>>>>                                         practice, for
>>>>>>>>>>>                                         various reasons,
>>>>>>>>>>>                                         many of which have
>>>>>>>>>>>                                         already been brought
>>>>>>>>>>>                                         previously. If you
>>>>>>>>>>>                                         have another way for
>>>>>>>>>>>                                         the client to get
>>>>>>>>>>>                                         its Registration
>>>>>>>>>>>                                         haven't seen
>>>>>>>>>>>                                             This is my
>>>>>>>>>>>                                             primary
>>>>>>>>>>>                                             should be no
>>>>>>>>>>>                                             the client
>>>>>>>>>>>                                             obtains to
>>>>>>>>>>>                                             update its
>>>>>>>>>>>                                             On 2013-05-31,
>>>>>>>>>>>                                             at 10:55, Justin
>>>>>>>>>>>                                                 referring to
>>>>>>>>>>>                                                 you could
>>>>>>>>>>>                                                 get that
>>>>>>>>>>>                                                 problem.
>>>>>>>>>>>                                                 (The
>>>>>>>>>>>                                                 writeups
>>>>>>>>>>>                                                 don't call
>>>>>>>>>>>                                                 this out
>>>>>>>>>>>                                                 explicitly
>>>>>>>>>>>                                                 but I would
>>>>>>>>>>>                                                 be willing
>>>>>>>>>>>                                                 to do so.)
>>>>>>>>>>>                                                 Or you could
>>>>>>>>>>>                                                 get it
>>>>>>>>>>>                                                 matter with
>>>>>>>>>>>                                                 any other
>>>>>>>>>>>                                                 Access
>>>>>>>>>>>                                                 having the
>>>>>>>>>>>                                                 token come
>>>>>>>>>>>                                                 from the
>>>>>>>>>>>                                                 endpoint
>>>>>>>>>>>                                                 would
>>>>>>>>>>>                                                 require a
>>>>>>>>>>>                                                 lot more
>>>>>>>>>>>                                                 work and
>>>>>>>>>>>                                                 complexity
>>>>>>>>>>>                                                 on behalf of
>>>>>>>>>>>                                                 both of the
>>>>>>>>>>>                                                 client and
>>>>>>>>>>>                                                 server.
>>>>>>>>>>>                                                 Either you
>>>>>>>>>>>                                                 end up with
>>>>>>>>>>>                                                 public
>>>>>>>>>>>                                                 need or with
>>>>>>>>>>>                                                 access to
>>>>>>>>>>>                                                 flow when
>>>>>>>>>>>                                                 they
>>>>>>>>>>>                                                 actually
>>>>>>>>>>>                                                 have it.
>>>>>>>>>>>                                                 Plus it adds
>>>>>>>>>>>                                                 don't buy
>>>>>>>>>>>                                                 you anything.
>>>>>>>>>>>                                                 05/31/2013
>>>>>>>>>>>                                                 10:15 AM,
>>>>>>>>>>>                                                 Phil Hunt wrote:
>>>>>>>>>>>                                                     is to
>>>>>>>>>>>                                                     have the
>>>>>>>>>>>                                                     issued
>>>>>>>>>>>                                                     through
>>>>>>>>>>>                                                     a unique
>>>>>>>>>>>                                                         don't understand
>>>>>>>>>>>                                                         *is*
>>>>>>>>>>>                                                         can
>>>>>>>>>>>                                                         They
>>>>>>>>>>>                                                         Full
>>>>>>>>>>>                                                         out
>>>>>>>>>>>                                                         use
>>>>>>>>>>>                                                         in
>>>>>>>>>>>                                                             I think

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Jun 2013 20:00:49 +0200

+1

On 2013-06-06, at 7:54 PM, Justin Richer <[email-masked]> wrote:

> ... My bad, you're right. I was getting my wires crossed with all these emails.
> 
> In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work. 
> 
> I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked. 
> 
>  -- Justin
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Jun 2013 11:05:07 -0700

I think we are getting to the source of the confusion.

To me, the client POSTING to the registration endpoint in federated scenarios is usually anonymous.  It can present signed registration claims. My preference was through a non-credential vector, like  the software_id parameter.  This is just registration information.

In your case, you are defining a local access token issued to a developer inside a single domain. This is no inter-op, so no need to specify.  I still would prefer that it be defined as local registration information, but in this case ONLY I can accept it is local authorization.

In this case, the process works the same, only now the client is no longer anonymous. It is just doing instance registration.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Jun 2013 14:19:30 -0400

Yes, this is exactly the case.

I think that signing/asserting/verifying registration information, if 
you want to do that, is better left to extensions from the basic draft. 
We have many documented use cases for using the structure and protocol 
as-is.

In BB+ we're using the initial access token mechanism to carry the 
signed information but defining discovery, token formats, and processing 
rules (and policies!) that make this actually work. We did this because 
carrying a signed chunk of information in a JWT is an established 
practice, as is using a JWT as an OAuth token, so it made sense to us. 
Putting that information inside of a software_id field with the same 
defined semantics would also be agreeable, I think, but I think we need 
a lot more eyes and hands on it. And either way, both of these 
mechanisms can be easily be built on top of the registration draft as is 
by either defining the processing of the initial access token (which is 
what BB+ does) or by defining a new metadata parameter (which is what 
you're suggesting), or even by providing some other mechanism that we 
haven't thought of yet.

So my question is: Are you OK with this functionality being defined as a 
proper extension so that the base draft can move forward (and that we 
take care not to *block* such an extension in the base draft), and do 
you want to help write that extension? I'd be happy to help write it, 
and I think we can probably get some of the BB+ group over here as well 
to offer input from that side. I also think that we can start to extract 
cross-domain OAuth token processing rules to provide real cross-domain 
interoperability, which would also be inherited by the registration draft.

  -- Justin

On 06/06/2013 02:05 PM, Phil Hunt wrote:
> To me, the client POSTING to the registration endpoint in federated 
> scenarios is usually anonymous.  It can present signed registration 
> claims. My preference was through a non-credential vector, like  the 
> software_id parameter.  This is just registration information.
>
> In your case, you are defining a local access token issued to a 
> developer inside a single domain. This is no inter-op, so no need to 
> specify.  I still would prefer that it be defined as local 
> registration information, but in this case ONLY I can accept it is 
> local authorization.
>
> In this case, the process works the same, only now the client is no 
> longer anonymous. It is just doing instance registration.
>
> Phil
>
> @independentid
>> In my view, the initial access token is, fundamentally, an access 
>> token used to constrain access to the registration endpoint (not the 
>> like a normal OAuth token is an opaque token used to constrain access 
>> to the protected resource. If you want to define anything more for 
>> either of those, you're going to need more work.
>>
>> goes beyond registration. And if registration is silent on all of 
>> this, and just says "the registration endpoint may be an OAuth 2.0 
>> protected resource", then whatever interoperable solutions we can 
>> come up with for validating a cross-domain token can be applied here. 
>> I don't think it makes sense to constrain registration before the 
>> rest of this work is baked.
>>
>>  -- Justin
>>
>>
>>>>> then normal access tokens.  This is for "registration" and does 
>>>>> not constitute authentication or authorization.
>>>>>
>>>>> This might be a good paper to look at so the group understands why 
>>>>> I am differentiating authorization from what is happening with 
>>>>> initial access:
>>>>>> issue that needs to be solved not just for registration. When it 
>>>>>> is solved in the wider case, Registration as-is will inherit the 
>>>>>> solution.
>>>>>>
>>>>>> I'd rather we solve the *real* cross-domain issue in the wider 
>>>>>> case than just try to cram something into registration.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>>>> As I've said before the initial auth token should nothing to 
>>>>>>>>> do with auth. It is simply an assertion given to the developer 
>>>>>>>>> to distribute in order to pass on signed claims about the 
>>>>>>>>> software.
>>>>>>>>
>>>>>>>> assertion to pass along signed claims is an artifact of it 
>>>>>>>> being an OAuth token and an OAuth token is an opaque string. 
>>>>>>>> Please read through the dynamic registration draft again -- it 
>>>>>>>> says absolutely nothing about assertions, signatures, or claims 
>>>>>>>> with regard to this token.
>>>>>>> It depends which case you are using.  If the developer is 
>>>>>>> talking to a single deployment domain and obtains an initial 
>>>>>>> access token and then ships it with all clients, then sure.  In 
>>>>>>> this scenario, the contents are totally controlled by the local 
>>>>>>> domain.
>>>>>>>
>>>>>>> Microsoft or Oracle app.  You want to be able to ship that to 
>>>>>>> your customers. You register with the appropriate publisher and 
>>>>>>> they give you a signed assertion that can be used as the 
>>>>>>> "Initial Access Token".    This token is then accepted by the 
>>>>>>> deployment domain and then it decides if it trusts the signer or 
>>>>>>> not.
>>>>>>>
>>>>>>> ===> For this to work, the contents and format of that token 
>>>>>>> MUST be defined. Otherwise how could we ensure a Microsoft 
>>>>>>> signed assertion would be accepted by a PingIdentity OAuth 
>>>>>>> server?  Or any other combination of implementations from 
>>>>>>> different vendors/communities?
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> contents and format of this token is out of scope leaves a 
>>>>>>>>> HUGE interop gap.
>>>>>>>>
>>>>>>>> The fact that some of us (myself included) are *using* this 
>>>>>>>> token to carry this kind of information is out of scope for the 
>>>>>>>> basic registration spec. I completely agree that there's value 
>>>>>>>> in defining this stuff, but as a separate and complementary 
>>>>>>>> spec from registration.
>>>>>>>
>>>>>>> [PH] I was reacting to John Bradley's assertion that the spec 
>>>>>>> was narrowly defined with interop in mind. Yet this mechanism is 
>>>>>>> a key factor being used to share information about the software.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> One criticism Hannes and others make of OAuth specs is they 
>>>>>>>>>> are not tightly profiled enough to be interoperable without 
>>>>>>>>>> further out of band configuration and profiling.
>>>>>>>>>>
>>>>>>>>>> Making registration work with minimal ambiguity was a 
>>>>>>>>>> priority for Connect and that has carried over.
>>>>>>>>>>
>>>>>>>>>> requires a registered client that may need to be registered 
>>>>>>>>>> to do the registration.
>>>>>>>>>>> Because bearer tokens have a stable RFC-numbered spec and 
>>>>>>>>>>> are widely implemented and the registration flow as 
>>>>>>>>>>> documented seems like it should work?  -T
>>>>>>>>>>> If we want to support stronger security mechanisms (which 
>>>>>>>>>>> the group has decided to work on already) then we need to 
>>>>>>>>>>> have a story on how to support the other mechanisms as well .