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
On 06/06/2013 10:48 AM, Manger, James H wrote:
John,
Why is the circularity of registration any different for a non-bearer
scheme?
A developer browsing a service portal can grab an id & secret, just as
easily as grabbing a bearer token, to configure into an app as the
initial access token
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
Inline.
On 2013-06-06, at 5:54 PM, Sergey Beryozkin wrote:
> Hi
> On 06/06/13 14:38, John Bradley wrote:
>> Perhaps it is better to say that from a security point of view a client must
>> only be redirected back to a URI that exactly matches a pre registered
>> redirect URI.
>>
>> The reasons
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
We haven't defined the various proof of possession tokens yet. It may be that
there are different registration requirements for clients being issued those
tokens.
It is possible that the client must have registered and pushed a public key to
the AS before it is issued a HoK token.
It may be j
We added this text to give examples of how to form the URL so that
server developers would be able to see common patterns. Without this
text, I heard from developers who thought that it *must* require a
client_id query parameter, or that it *must* be a URL template, or that
it *must* be differe
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
John,
Why is the circularity of registration any different for a non-bearer scheme?
A developer browsing a service portal can grab an id & secret, just as easily
as grabbing a bearer token, to configure into an app as the initial access
token.
A client registration endpoint can return an id & s
Perhaps it is better to say that from a security point of view a client must
only be redirected back to a URI that exactly matches a pre registered redirect
URI.
The reasons for that should be clear from Facebooks recent issues with trying
to pattern match.
In the instance where there is exact
Folks,
Roland and I are planning for an OAuth2.0 Interop event at MIT Campus
(Boston, USA) during the week prior to the IETF88-Vancouver. The event
will be co-sponsored by ISOC and MIT-KIT.
Here's some more info:
(1) Dates: Thursday-Friday Oct 31 and Nov 1, 2013.
(2) Venue: MIT Campus, Ca
On the face of it I think adding proof of possession aught to be possible.
The hard part will be that those mechanisms assume a registered client.
I think the trick will be not crating a circular registration problem.
Adding the other token types to the RS will be simple in comparison.
Joh
That's fair, John.
Having a mandatory-to-implement mechanism in place is certainly useful. Pushing
stronger security mechanisms to other specifications is also fine. It would be
good to re-read the document to see whether we can actually fit the currently
worked on security mechanisms into the
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
21 matches
Mail list logo
