... 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:
We have two separate discussions going on. 8-)
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
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
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.
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 <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
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
On 06/06/2013 01:33 PM, Phil Hunt wrote:
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On 2013-06-06, at 10:05 AM, Justin Richer wrote:
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.
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.
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.
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.
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 empirically disagree with that statement.
-- Justin
Phil
On 2013-06-06, at 1:53, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
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.
On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN -
FI/Espoo)" <hannes.tschofe...@nsn.com
<mailto:hannes.tschofe...@nsn.com>> wrote:
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 .
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
