Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Justin Richer <jricher <at> mitre.org>
2013-06-06 17:49:57 GMT
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:
Huh?
There's no need for public clients to access the token
endpoint as they can register anonymously.
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
On 06/06/2013 01:43 PM, Phil
Hunt wrote:
*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.
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
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.
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:
On
06/06/2013 01:17 PM, Phil Hunt
wrote:
On 2013-06-06, at 9:49
AM, Justin Richer wrote:
Tim,
thanks for your review!
Comments inline.
On
06/05/2013 04:59 PM, 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?)
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".
[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.
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.
[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
protected API.
[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 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
<div>
Then how do they get their equivalent of a registration access token
to manage their configurations? <br><br>
The draft proposes that they get this token right from the
registration endpoint. You're proposing that they get this from the
token endpoint.<br><br>
The initial access token isn't even in play here.<br><br>
-- Justin<br><br><div class="moz-cite-prefix">On 06/06/2013 01:49 PM, Phil Hunt
wrote:<br>
</div>
<blockquote cite="mid:FCAFE2AE-BDAD-4576-BF9C-E6AD01AFAF2B <at> oracle.com" type="cite">
Huh?
<div><br></div>
<div>There's no need for public clients to access the token
endpoint as they can register anonymously.</div>
<div>
<br><div apple-content-edited="true">
<span class="Apple-style-span"><span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<div>
<div>
<div>Phil</div>
<div><br></div>
<div> <at> independentid</div>
<div><a moz-do-not-send="true" href="http://www.independentid.com">www.independentid.com</a></div>
</div>
</div>
</div>
</span><a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com">phil.hunt <at> oracle.com</a><br><br>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div>
<div>On 2013-06-06, at 10:47 AM, Justin Richer wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> Because anonymous
*registration* and public client *access* to the token
endpoint are two different things.<br><br>
-- Justin<br><br><div class="moz-cite-prefix">On 06/06/2013 01:43 PM, Phil
Hunt wrote:<br>
</div>
<blockquote cite="mid:C6D96900-B0F9-4B5B-B5D4-D2470D5B9EFE <at> oracle.com" type="cite">
<div>*why* will the 6749 standard flows (specifically
4.4) not work?</div>
<div><br></div>
<div>The registration endpoint can allow anonymous
access to permit anonymous registration.</div>
<div><br></div>
<div>This means the configuration endpoints can use
normal access tokens obtained through RFC6749 section
4.4 (Client Auth) flows.</div>
<div>
<br><div>
<div>
<div apple-content-edited="true"> <span class="Apple-style-span"><span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<div>
<div>
<div>Phil</div>
<div><br></div>
<div> <at> independentid</div>
<div><a moz-do-not-send="true" href="http://www.independentid.com/">www.independentid.com</a></div>
</div>
</div>
</div>
</span><a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com">phil.hunt <at> oracle.com</a><br><br>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div>
<div>On 2013-06-06, at 10:36 AM, Justin Richer
wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> ...
because it already *is* a REST protected
API. It's protected with the Registration
Access Token. Which is an OAuth 2.0 Bearer
token. <br><br>
The *only* difference is how you get the
token, which has nothing to do with the REST
protected API that it's protecting.<br><br>
-- Justin<br><br><div class="moz-cite-prefix">On 06/06/2013
01:35 PM, Phil Hunt wrote:<br>
</div>
<blockquote cite="mid:F4DE1CDB-20F3-4106-8875-A88B3FB78712 <at> oracle.com" type="cite"> 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.
<div>
<br><div apple-content-edited="true"> <span class="Apple-style-span"><span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<div>
<div>
<div>Phil</div>
<div><br></div>
<div> <at> independentid</div>
<div><a moz-do-not-send="true" href="http://www.independentid.com/">www.independentid.com</a></div>
</div>
</div>
</div>
</span><a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com">phil.hunt <at> oracle.com</a><br><br>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div>
<div>On 2013-06-06, at 10:28 AM,
Justin Richer wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> I feel we're still
just going in circles with these
arguments, but my comments are
inline:<br><br><div class="moz-cite-prefix">On
06/06/2013 01:17 PM, Phil Hunt
wrote:<br>
</div>
<blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite"> <br><div apple-content-edited="true">
<span class="Apple-style-span"><span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<span class="Apple-style-span">
<div>
<div>
<div>
<div>Phil</div>
<div><br></div>
<div> <at> independentid</div>
<div><a moz-do-not-send="true" href="http://www.independentid.com/">www.independentid.com</a></div>
</div>
</div>
</div>
</span><a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com">phil.hunt <at> oracle.com</a><br><br>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div>
<div>On 2013-06-06, at 9:49
AM, Justin Richer wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> Tim,
thanks for your review!
Comments inline.<br><br><div class="moz-cite-prefix">On
06/05/2013 04:59 PM, Tim
Bray wrote:<br>
</div>
<blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">FWIW, I
just read the spec
through with fresh
eyes, and I found the
explanation of the
workflow in 1.4.2 very
useful.
<div>
<br><div>- A developer
manually registers
and then is able
to request
“Initial tokens”
tokens for a
dynamic-app-registration-scope, </div>
<div>- 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</div>
<div>- you
fetch/update/delete
your registration
information with
that registration
token.</div>
<div><br></div>
<div>The first part,
where the
developer
registers &
gets a token for a
scope, is vanilla
OAuth 2. (right?)
<br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br><br><blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>The bit about
getting an access
token specific to
that registration
is a new flow
(right?), but it
seems convenient.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
</div>
</blockquote>
<div><br></div>
[PH] We still greatly disagree
on this.</div>
<div><br></div>
<div>*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".</div>
<div><br></div>
</blockquote>
<br>
[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.<br><br><blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite">
<div>As soon as you do this,
other things simplify.</div>
<div><br></div>
<div>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.</div>
</blockquote>
<br>
[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.<br><br><blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite">
<div>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?</div>
</blockquote>
<br>
[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.<br><br>
Forced uniformity isn't
necessarily a good thing.<br><br><blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite">
<div>3. The
registration/configuration API
is JUST a normal OAuth2
protected API.</div>
</blockquote>
<br>
[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. <br><br><blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite">
<div><br></div>
<div>If the draft drops
"registration access tokens",
a lot of the text in the draft
disappears. The whole spec is
much simpler.</div>
</blockquote>
<br>
[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.<br><br><blockquote cite="mid:7B00614C-6B25-4951-B004-C17932432D17 <at> oracle.com" type="cite">
<div>
<br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br><blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div> 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. <br>
</div>
</div>
</div>
</blockquote>
<br>
Right, and I've admitted
that "Initial Access
Token" a crappy name, but
I haven't heard a better
suggestion yet. <br><br><blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div><br></div>
<div>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. <br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br><br><blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div><br></div>
<div>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.</div>
<div><br></div>
</div>
</div>
</blockquote>
<br>
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.<br><br>
Thanks,<br>
-- Justin<br><br><blockquote cite="mid:CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA <at> mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div> -T</div>
<div><br></div>
<div>
<br><div><br></div>
<div><br></div>
</div>
</div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On
Fri, May 31, 2013 at
1:04 PM, Donald F
Coffin <span dir="ltr"><<a moz-do-not-send="true" href="mailto:donald.coffin <at> reminetworks.com" target="_blank">donald.coffin <at> reminetworks.com</a>></span>
wrote:<br><blockquote class="gmail_quote">
<div bgcolor="white" link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span>See
my comments
inline [DFC]</span></p>
<div class="im">
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal"><span>Best
regards,</span></p>
<p class="MsoNormal"><span>Don</span></p>
<p class="MsoNormal"><span>Donald
F. Coffin</span></p>
<p class="MsoNormal"><span>Founder/CTO</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>REMI
Networks</span></p>
<p class="MsoNormal"><span>22751
El Prado Suite
6216</span></p>
<p class="MsoNormal"><span>Rancho
Santa
Margarita, CA
92688-3836</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>Phone:
<a moz-do-not-send="true" href="tel:%28949%29%20636-8571" value="+19496368571" target="_blank">(949)
636-8571</a></span></p>
<p class="MsoNormal"><span>Email:
<a moz-do-not-send="true" href="mailto:donald.coffin <at> reminetworks.com" target="_blank"><span>donald.coffin <at> reminetworks.com</span></a></span></p>
</div>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span>From:</span><span>
Justin Richer
[mailto:<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>] <br>Sent:
Friday, May
31, 2013 12:40
PM<br>To:
Phil Hunt<br>Cc:
Donald F
Coffin; <a moz-do-not-send="true" href="mailto:oauth <at> ietf.org" target="_blank">oauth <at> ietf.org</a></span></p>
<div class="im">
<br>Subject:
Re: [OAUTH-WG]
review
comments on
draft-ietf-oauth-dyn-reg-11.txt</div>
</div>
</div>
<div> <br class="webkit-block-placeholder">
</div>
<p class="MsoNormal">I feel the need to clarify a couple
erroneous
things in
Phil's
statement:</p>
<div class="im">
<br><br>
* 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.<span></span>
</div>
<p class="MsoNormal"><span>[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<br>
without the
threads
becoming so
convoluted no
one is able to
make sense or
even
comprehend the
point being
discussed.</span></p>
<div class="im">
<p class="MsoNormal"><br>
* 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.<span></span></p>
</div>
<p class="MsoNormal"><span>[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<br>
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<br>
implementation
does NOT
support the
implicit flow,
that use case
is one we have
elected NOT to
support.</span></p>
<p class="MsoNormal"><span>
[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.</span></p>
<div>
<div class="h5">
<p class="MsoNormal"><br>
-- Justin</p>
<div>
<p class="MsoNormal">On
05/31/2013
03:33 PM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Don,</p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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.<br><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-31,
at 15:16,
Donald F
Coffin <<a moz-do-not-send="true" href="mailto:donald.coffin <at> reminetworks.com" target="_blank">donald.coffin <at> reminetworks.com</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal"><span>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?</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>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.</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>Just my two
cents.</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal"><span>Best
regards,</span></p>
<p class="MsoNormal"><span>Don</span></p>
<p class="MsoNormal"><span>Donald F.
Coffin</span></p>
<p class="MsoNormal"><span>Founder/CTO</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>REMI
Networks</span></p>
<p class="MsoNormal"><span>22751 El
Prado Suite
6216</span></p>
<p class="MsoNormal"><span>Rancho
Santa
Margarita, CA
92688-3836</span></p>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
<p class="MsoNormal"><span>Phone:
<a moz-do-not-send="true" href="tel:%28949%29%20636-8571" value="+19496368571" target="_blank">(949)
636-8571</a></span></p>
<p class="MsoNormal">
<span>Email:
<a moz-do-not-send="true" href="mailto:donald.coffin <at> reminetworks.com" target="_blank">donald.coffin <at> reminetworks.com</a></span></p>
</div>
<div> <span> </span><br class="webkit-block-placeholder">
</div>
<div>
<div>
<p class="MsoNormal"><span>From:</span><span>
Phil Hunt [<a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com" target="_blank">mailto:phil.hunt <at> oracle.com</a>]
<br>Sent:
Friday, May
31, 2013 11:11
AM<br>To:
Justin Richer<br>Cc: <a moz-do-not-send="true" href="mailto:oauth <at> ietf.org" target="_blank">oauth <at> ietf.org</a>
WG<br>Subject:
Re: [OAUTH-WG]
review
comments on
draft-ietf-oauth-dyn-reg-11.txt</span></p>
</div>
</div>
<div> <br class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal">To
be clear. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">It
is two
separate
issues. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">1.
Anonymous
clients can
easily be
handled
through policy
config. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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. <br><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-31,
at 13:58,
Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">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.<br><br>
I'm sorry, but
your proposed
solution will
simply not
work.<br><br>
-- Justin</p>
<div>
<p class="MsoNormal">On
05/31/2013
01:56 PM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Well
the only
client that
wouldn't have
a credential
is an implicit
client. An
implicit
client is
transient and
so would never
update. <br><br>
Besides, as i
have stated,
implicit
clients should
not use dyn
reg. </p>
</div>
<div>
<p class="MsoNormal"><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-31,
at 13:41,
Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">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!<br><br>
-- Justin<br><br><br></p>
<div>
<p class="MsoNormal">On
05/31/2013
12:58 PM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Yes.
I specified
the trivial
solution to
anonymous
clients
earlier.</p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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. </p>
</div>
<div>
<p class="MsoNormal"><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-31,
at 12:34,
Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">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.<br><br>
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.<br><br>
Again, thanks
for your
thorough
review, Phil,
and I look
forward to
future
feedback.<br><br>
-- Justin</p>
<div>
<p class="MsoNormal">On
05/31/2013
12:28 PM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">I
disagree. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">There
is absolutely
no need for a
registration
access token. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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?</p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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?</p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">Why
force the
client to
persist
multiple
tokens and
creds? That is
far far too
complex. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">Finally
if you get rid
of
registration
access token
the spec size
will drop
roughly in
half IMO. This
suggests
simplicity to
me. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">Apologies
for my rant.
Maybe we
should park
this for now.
We are going
in circles. <br><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"> <br>
On 2013-05-31,
at 11:25,
Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal"> Phil,<br><br>
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.<br><br>
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.<br><br>
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.<br><br>
-- Justin</p>
<div>
<p class="MsoNormal">On
05/31/2013
11:10 AM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Justin,</p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">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. <br><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-31,
at 10:55,
Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Which token are you referring to here?<br><br>
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.<br><br>
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.<br><br>
-- Justin</p>
<div>
<p class="MsoNormal">On
05/31/2013
10:15 AM, Phil
Hunt wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">The
preference is
to have the
access token
for
registration
issued by the
normal token
server rather
then by the
registration
endpoint. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">In
the current
draft it is
obtained
through a
unique process
and must
outlive the
client. </p>
</div>
<div>
<p class="MsoNormal">
<br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-30,
at 19:47,
"Richer,
Justin P."
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<div>
<p class="MsoNormal"><span>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.<br><br>
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.<br><br>
You seem to be
asking for
something
that's already
in the draft.<br><br>
-- Justin</span></p>
<div>
<div class="MsoNormal" align="center">
</div>
<div>
<p class="MsoNormal"><span>From:</span><span>
Phil Hunt [<a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com" target="_blank">phil.hunt <at> oracle.com</a>]<br>Sent:
Thursday, May
30, 2013 7:31
PM<br>To:
Richer, Justin
P.<br>Cc:
John Bradley;
<a moz-do-not-send="true" href="mailto:oauth <at> ietf.org" target="_blank">oauth <at> ietf.org</a> WG<br>Subject:
Re: [OAUTH-WG]
review
comments on
draft-ietf-oauth-dyn-reg-11.txt</span></p>
</div>
<div>
<div>
<p class="MsoNormal"><br><br>
Phil</p>
</div>
<div>
<p class="MsoNormal"><br>
On 2013-05-30,
at 16:11,
"Richer,
Justin P."
<<a moz-do-not-send="true" href="mailto:jricher <at> mitre.org" target="_blank">jricher <at> mitre.org</a>>
wrote:</p>
</div>
<blockquote>
<div>
<div>
<p class="MsoNormal"><span>Comments
inline, marked
by [JR].</span></p>
<div>
<div class="MsoNormal" align="center">
</div>
<div>
<p class="MsoNormal"><span>From:</span><span>
Phil Hunt [<a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com" target="_blank">phil.hunt <at> oracle.com</a>]<br>Sent:
Thursday, May
30, 2013 5:25
PM<br>To:
Richer, Justin
P.<br>Cc:
John Bradley;
<a moz-do-not-send="true" href="mailto:oauth <at> ietf.org" target="_blank">oauth <at> ietf.org</a> WG<br>Subject:
Re: [OAUTH-WG]
review
comments on
draft-ietf-oauth-dyn-reg-11.txt</span></p>
</div>
<div>
<p class="MsoNormal">See
below.</p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span>Phil</span></p>
</div>
<div>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal"><span> <at> independentid</span></p>
</div>
<div>
<p class="MsoNormal"><span><a moz-do-not-send="true" href="http://www.independentid.com/" target="_blank">www.independentid.com</a></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span><a moz-do-not-send="true" href="mailto:phil.hunt <at> oracle.com" target="_blank">phil.hunt <at> oracle.com</a></span></p>
</div>
<div>
<span> </span><br class="webkit-block-placeholder">
</div>
</div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div> <br class="webkit-block-placeholder">
</div>
<div>
<div>
<p class="MsoNormal">On
2013-05-30, at
2:09 PM,
Justin Richer
wrote:</p>
</div>
<p class="MsoNormal"><br><br><br></p>
<div>
<p class="MsoNormal">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.)
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div> <br class="webkit-block-placeholder">
</div>
</div>
</blockquote>
</blockquote>
<div> <br class="webkit-block-placeholder">
</div>
</div>
</blockquote>
</blockquote>
<div> <br class="webkit-block-placeholder">
</div>
</div>
</blockquote>
</div>
</blockquote>
</blockquote>
<div> <br class="webkit-block-placeholder">
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OAuth mailing list<br><a moz-do-not-send="true" href="mailto:OAuth <at> ietf.org">OAuth <at> ietf.org</a><br><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
RSS Feed