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 <jric...@mitre.org
<mailto:jric...@mitre.org>> 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." <jric...@mitre.org
<mailto:jric...@mitre.org>> 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 [phil.h...@oracle.com <mailto:phil.h...@oracle.com>]
*Sent:* Thursday, May 30, 2013 7:31 PM
*To:* Richer, Justin P.
*Cc:* John Bradley; oauth@ietf.org <mailto:oauth@ietf.org> 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." <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Comments inline, marked by [JR].
------------------------------------------------------------------------
*From:* Phil Hunt [phil.h...@oracle.com <mailto:phil.h...@oracle.com>]
*Sent:* Thursday, May 30, 2013 5:25 PM
*To:* Richer, Justin P.
*Cc:* John Bradley; oauth@ietf.org <mailto:oauth@ietf.org> 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>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
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.) But that's neither here nor there, as you can
already do what you're asking for and I think I can clear things up:
In your case, the "3rd party bearer assertion" is simply *not*
the Initial Registration Token. It's an assertion that can be
used to *get* an Initial Registration Token. The token that you
get from the Token Endpoint, in your case, would be "local" from
your own AS. Your registration endpoint would look at this token
on the way in, know how to validate it, do whatever else it wants
to with it, and process the registration. Then it would issue a
Registration Access Token that to the registering client to use
at the RESTful endpoint. Incidentally, that token would also be
"local", just like before.
How you (the client/developer) get the actual Initial
Registration Token is completely and forever out of scope for the
Dynamic Registration spec.
[PH] Yes, the issuance of the third party bearer assertion token
token would be out of scope of this spec.
If however the group decides to except federated direct access
tokens as registration *access* tokens, then I think we have to
define federation for access tokens first. For me, I think this
is something that should be discussed in a different charter.
[JR] It's an access token, plain and simple. The draft doesn't
care -- and shouldn't care -- if it's federated or not. I agree,
and have been arguing all along, that if you have a use case for
federated access tokens, you need to define the mechanisms for
such tokens, and that registration is *not* the place for that
definition.It's orthogonal but they can be used together. Let's
define them separately but ina compatible way.
[ph] thats not the impression i get from the draft. As i mentioned
earlier using access token for registration is clearer.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
