Justin,
Thanks. I think this resolved all of my syntax issues.
The lifecycle text is very helpful.
I still want to continue discussion on initial access and reg access. We can
address in other threads.
Thx
Phil
On 2013-05-24, at 14:10, "Richer, Justin P." wrote:
> New Dynamic Registrati
The use cases I have heard of from Justin and Morteza at IIW are based on
federated scenarios. These are not just locally asserted tokens.
Your assertion that the tokens are local and my assertion they are federated
suggests there are things that must be sorted out/understood.
I'm merely implyi
Phil,
The OAuth token used authorize access to the registration endpoint( if one is
required) would be issued by the registration server via some method eg cut and
paste from a developer portal, email or perhaps via OAuth to a Developer API
management application. That is declared out of sc
=nat via iPhone
May 25, 2013 7:16、Phil Hunt wrote:
On 2013-05-24, at 2:54 PM, John Bradley wrote:
I agree with Justin.
If you want tight authentication on the AS that issues the tokens we can
use OAuth for that with short lived tokens granted based on a SAML SSO ,
PIV card or whatever float
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-24, at 2:54 PM, John Bradley wrote:
> I agree with Justin.
>
> If you want tight authentication on the AS that issues the tokens we can use
> OAuth for that with short lived tokens granted based on a SAML SSO , PIV c
I agree with Justin.
If you want tight authentication on the AS that issues the tokens we can use
OAuth for that with short lived tokens granted based on a SAML SSO , PIV card
or whatever floats your boat for authentication.
How the tokens are issued to the OAuth client doing the registration (n
Phil,
I think the horse is out of the barn on implicit flow.
Many websites use implicit rather than code now, it is no worse, and perhaps
better than using code flow with a client that is not confidential( though
Dynamic registration can dix the public client code flow problem for native
apps
I can see what you're trying to do there, but I agree that it's a bit of a
non-starter. It assumes that clients even can be expired (which requires
time-based processing of a client, not something most AS's are set up to do
today, though it's far from impossible). And an in-browser client is lik
New Dynamic Registration draft is published, incorporating much of the
discussion from the group this week.
Some normative changes that should have minimal impact:
- "expires_at" is now "client_secret_expires_at"
- "issued_at" is now "client_id_issued_at"
- creation of an IANA registry for to
I completely disagree with this assessment. The latest draft (which was just
posted) has new language describing what this token is and what it's for, and I
hope that will clear things up. But even so, let me try to address your
concerns in-line.
On May 24, 2013, at 4:02 PM, Phil Hunt
mailto:p
I expect this is a non-starter, but dyn-reg *could* allow the client ti
include a "please expire me in xx min" flag in the registration request
(avoiding need for explicit cleanup later).
-J
On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. wrote:
> I agree with Josh, and I believe that this
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Protocol
Author(s) : Justin Richer
I agree with Josh, and I believe that this kind of application should
definitely be supported. One of my goals with the Dynamic Registration draft
was to make it so that it could be used for all the various flavors of OAuth
that people are using today. But that said, I'm not at all against givin
I think this discussion mixes two separable questions:
1. Should dyn-reg support client-side browser-based apps (which need
client_ids for each AS they talk to, even if they only talk briefly and
then throw the credentials away)?
2. Which authorization flows are available to clients?
I have exa
I have been struggling with the concept of an initial client credential covered
in the current draft (rev 10):
The Client Registration Endpoint MAY accept an initial authorization
credential in the form of an OAuth 2.0 [RFC6749] access token in
order to limit registration to only previously
I wanted to bring out a quick discussion to ask the question if it makes sense
to support implicit clients in dynamic registration.
By definition, implicit clients are unauthenticated. Therefore the only purpose
to register an implicit client is to obtain a client_id with a particular AS
instan
> As I recall, the argument was that without this, someone could just keep
> fishing at the
> token revocation endpoint for valid tokens. Though thinking about it now,
> even if you
> did get a "token was valid" response, the token wouldn't be valid anymore and
> it wouldn't
> do you much good.
As I recall, the argument was that without this, someone could just keep
fishing at the token revocation endpoint for valid tokens. Though thinking
about it now, even if you did get a "token was valid" response, the token
wouldn't be valid anymore and it wouldn't do you much good.
It's possibl
> Sergey has the correct interpretation -- it's to prevent a class of oracle
> attacks.
> Think of it this way, if you go to revoke a token, and the token wasn't there
> in the
> first place, the end result is the same: the token's not there when you're
> done. So
> it's a 200 because the result
Sergey has the correct interpretation -- it's to prevent a class of oracle
attacks. Think of it this way, if you go to revoke a token, and the token
wasn't there in the first place, the end result is the same: the token's not
there when you're done. So it's a 200 because the result is what you w
Hi
On 23/05/13 21:57, Lewis Adam-CAL022 wrote:
Hi,
Section 2.2 (Revocation Response) of draft-ietf-oauth-revocation-09 states:
The authorization server responds with HTTP status code 200 if the
token has been revoked sucessfully or if the client submitted an
invalid token. The conten
21 matches
Mail list logo
