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 prote
Phil
On 2013-05-30, at 16:11, "Richer, Justin P." wrote:
> Comments inline, marked by [JR].
>
> From: Phil Hunt [phil.h...@oracle.com]
> Sent: Thursday, May 30, 2013 5:25 PM
> To: Richer, Justin P.
> Cc: John Bradley; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] review comments on draft-ietf-o
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Justin,
So far, every time an OAuth server has accepted a 3rd party token it has been a
bearer assertion. The common pattern is to exchange that assertion for a an
access token issued by the local server for the local resource endpoint.
That's the pattern I am trying to follow.
Going this way
I don't understand which access token is being talked about here -- is
this the Initial Registration Token? Because you can already do
everything below. How you get the Initial Registration token is out of
scope precisely so that the AS can decide what that means. We can add
language in the lif
For this, I would suggest:
Anonymous, user assisted registration - client registers using the client
credential flow but may use an administrator (in the case of web app) or
end-user (uid/password) . Since resource owner would still require separate
credential, then the client flow could be us
But this still doesn't address clients who don't have a client_secret.
Do they now need one in order to talk to the registration endpoint? What
you're suggesting is that a client use one set of credentials to get
access tokens and another set of credentials to get registrations. This
is certain
It's hard to say what the best solution here is regarding clarifications until
we get clarity on the issue of registration access token.
I don't think using a client credential flow to obtain an access token to the
registration endpoint is complex. It's the normal flow.
I concede that you are
Thanks for clearing up where the confusion was taking place. I had tried
to make it clear that these were absolutely standard, opaque OAuth2
bearer tokens and absolutely standard OAuth2-protected endpoints, but if
that's not clear that needs to be updated. This is what the text says
right now:
I see what is happening.
I think the reason why I find this spec sooo confusing is that the terms imply
new token types when they don't.
For example when you say "Registration Access Token" and "Initial Access Token"
it implies to me that it is a totally new token type (and in one case it sorta
The issue is that it has different issuing/lifecycle than normal. E.g. Why is
it issued by the registration endpoint?
Why doesn't the client just request an access token using its client credential
for the registration endpoint when it wants to update its profile?
Phil
@independentid
www.indep
What I don't understand is that the existing structure also allows for
exactly that same use case. The difference is where the information is
carried. But since we're not locking down where or how that information
is specified, your application use case can do it how it makes sense.
I fully ag
The reg access token is a OAuth bearer token that is issued as part of the
registration response and used to access the new client resource for reads and
or updates depending on the permissions.
They are both oauth access tokens.
On 2013-05-30, at 12:02 PM, Phil Hunt wrote:
> Seriously. The n
Justin,
You are right, 6750 does not define "local" or "3rd party". But the use cases
we are talking about are clearly very very different.
You are blurring the distinction between access tokens and bearer assertions
such as defined by draft-ietf-oauth-saml2-bearer and
draft-ietf-oauth-jwt-bea
But OAuth says nothing about whether tokens are "local" or "3rd party",
and this spec inherits that definition. The AS is free to do whatever it
wants with the token. You can already do both scenarios that you're
talking about below with the existing functionality (in a way that makes
sense), s
In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access
token to an anonymous client to begin the registration process (just not sure
the value of it).
I'm not ok with what is happening in 1.4.2 (Protected Registration).
I think we should make it clear that it is for P
These were not introduced in the new draft, they were just explained
better.
The Client Registration Endpoint has been (optionally) OAuth protected
all along. The Initial Registration Token is an authorization token (not
authentication) used to access that protected resource.
The Client Conf
The initial access token is a OAuth bearer Access token (Authz). Like any
bearer token it can be structured or not. Your concern is I think around some
work BB+ has done to profile a structured token for this particular RS use.
That is out of scope for the core of dynamic registration, as i
Seriously. The new dyn reg draft introduces two new tokens. The initial reg
token and the registration access token.
As for the latter, the reg access token, my understanding is it has nothing to
do with an access token. It is issued *after* registration to allow reg
updates. Right? I know so
I still "argue" that the initial client access token (not assertion) is
really just an authorization token for the endpoint (like any other
OAuth2 protected resource). There is nothing within OAuth2 that
precludes a system using structured authorization tokens that contain
claims and using that
No different issue. I was concerned about the initial client assertion being
passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-)
Phil
On 2013-05-30, at 8:48, John Bradley wrote:
> I think Phil also had some processing reason why a Tok
I think Phil also had some processing reason why a Token endpoint or RS
wouldn't want to tale the authentication as a header, as the processing was
easier with them as parameters as they are potentially available to different
parts of the stack. That may have been mostly around RS, but the pri
On May 30, 2013, at 11:18 AM, Torsten Lodderstedt
wrote:
> Hi Justin,
>
> see below :-)
>
> Justin Richer schrieb:
>
>> Torsten, thanks -- responses inline.
>>
>> On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
>>> Hi Justin,
>>>
>>> comments inline.
>>>
>
> section 1.4
>
Torsten, thanks -- responses inline.
On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
Hi Justin,
comments inline.
section 1.4
How is the client supposed to identify/distinguish authorization
servers? Based on the Client Registration Endpoint URI?
Authorization server identification is n
Hi Justin,
comments inline.
section 1.4
How is the client supposed to identify/distinguish authorization
servers? Based on the Client Registration Endpoint URI? Authorization
server identification is necessary in order to map client_ids to
authorization servers for clients, which are conne
25 matches
Mail list logo
