Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

I fundamentally disagree with that too.  OAuth 2 is the *framework*, one which supports multiple token types.  Bearer tokens were the first credential type defined. OAuth 1.0a also requires HTTPS transport for authentication and getting the token. There are  real use cases for tokens usable ov

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill, OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTT

Re: [OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15

Thanks for the feedback Prateek. I've tried to address some of you comments and questions inline below. On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra wrote: > It would be helpful if the draft identified the various cases that are > intended to be supported. For example, > in draft-ietf-oauth-a

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solving" means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP.  1.0a s

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Origin

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

Does the term "Active" help clarify the meaning but still confirm to your intention, Justin? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email:

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Prateek, My point was that a public client could very easily and safely be issued a secret in the form of an OAuth token. This includes any type of signing key that the MAC/etc token would want to use. What public client's can't have are configuration-time keys, like a client_secret. It's imp

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Justin - my comment was scoped to *key distribution* - not to the general use of public clients. I was wondering how one can distribute keys or have key agreement between an AS and a client, if there is no existing trust relationship between them. Maybe there is some clever crypto way of achie

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Regarding the question of AS to RS communication, I think capturing it is a reasonable task but not one essential to this activity. So my view would be to exclude it from consideration in this groups activity. We have many use-cases where support for confirmation that goes beyond the currently

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

On 2013-02-14, at 11:20 AM, Justin Richer wrote: > > On 02/14/2013 09:05 AM, John Bradley wrote: >> I agree with Tim that is the behaviour I would expect to see with DELETE >> though I have a rd time seeing a server ever honouring it. >> >> I guess that we need to clarify what happens with P

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

On 02/14/2013 09:05 AM, John Bradley wrote: > I agree with Tim that is the behaviour I would expect to see with DELETE > though I have a rd time seeing a server ever honouring it. > > I guess that we need to clarify what happens with PUT and claims the server > has defaults for, perhaps some th

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

I agree with Tim that is the behaviour I would expect to see with DELETE though I have a rd time seeing a server ever honouring it. I guess that we need to clarify what happens with PUT and claims the server has defaults for, perhaps some that are not changeable by the client. Is not includ

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

On 02/14/2013 02:45 AM, Hannes Tschofenig wrote: Hi Prateek, thanks for your questions. On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote: Hannes, 1) Its not clear to me that we need to specify exchanges between the AS and the RS as part of this work. The core specification leaves this

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

+1 to this. And I'd also be fine if it wasn't MTI (server returns a 405 Method Not Allowed) for servers that don't want to do it at all. -- Justin On 02/13/2013 04:26 PM, Tim Bray wrote: A DELETE is an http request that asks the server to delete something. We probably would want to avoid wr

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

I noticed that the latest Token Revocation draft [1] has introduced the parameter "token_type_hint". I would suggest the same here, as that would make what is meant by "valid" much clear.. [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 Thanks & regards, -Prabath On Tue, Feb 12, 2

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt

Hi On 13/02/13 22:19, Torsten Lodderstedt wrote: Hi all, I just published a new revision, which should cover all the issues raised/dicussed during WGLC. I applied the following changes: - introduced a new parameter "token_type_hint", which a client may use to give the authorization server a hin