I think we are getting to the source of the confusion.
To me, the client POSTING to the registration endpoint in federated scenarios
is usually anonymous. It can present signed registration claims. My preference
was through a non-credential vector, like the software_id parameter. This is
jus
... 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 no
We have two separate discussions going on. 8-)
Phil
@independentid
www.independentid.com
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/201
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 in
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 author
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
Phil
@independentid
www.independentid.com
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
a later stage or whether there are some problems with the
extensibility story.
Ciao
Hannes
*From:*ext John Bradley [mailto:ve7...@ve7jtb.com <http://ve7jtb.com>]
*Sent:*Thursday, June 06, 2013 11:54 AM
*To:*Tschofenig, Hannes (NSN - FI/Espoo)
*Cc:*ext Tim Bray; Manger, James H; oauth
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, tha
James, thanks for the review.
On 06/06/2013 12:06 AM, Manger, James H wrote:
BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is
deliberately extensible to support other sorts of credentials (eg MAC
authentication).
Why is draft-ietf-oauth-dyn-reg hardwired to only support BEAR
tokens (whatever that is for this AS) would be even more useful.
>
> --
> James Manger
>
> From: John Bradley [mailto:ve7...@ve7jtb.com]
> Sent: Thursday, 6 June 2013 7:22 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: ext Tim Bray; Manger, James H; oauth@ietf.org
&
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.
Bearer or not bearer is a distraction. The fact that the contents and format of
this token is out of s
y [mailto:ve7...@ve7jtb.com<http://ve7jtb.com>]
Sent: Thursday, June 06, 2013 11:54 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ext Tim Bray; Manger, James H; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
There are a coupl
tb.com]
> Sent: Thursday, June 06, 2013 11:54 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: ext Tim Bray; Manger, James H; oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
>
> There are a couple of reasons.
>
> One criticism Han
t: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
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 mi
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 ca
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
AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately
extensible to support other sorts of credentials (eg MAC authentication).
Why is draft-ietf-oauth-dyn-reg hardwired to only support
BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately
extensible to support other sorts of credentials (eg MAC authentication).
Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens?
1.3. “Registration Tokens and Credentials” says:
“The Initial Access
19 matches
Mail list logo
