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 <jric...@mitre.org
<mailto:jric...@mitre.org>> 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 <jric...@mitre.org
<mailto:jric...@mitre.org>> 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 <jric...@mitre.org
<mailto:jric...@mitre.org>> 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 <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.)
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
