Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

Hi all, we should probably adopt the wording to refer to the access grant underlying all tokens? Something like: "based on the same access grant ...". What do you think? regards, Torsten. doug foiles schrieb: Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment on wh

Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

Hi all, can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs. regards, Torsten. Jianhua Shao schrieb: Hello, Dynamic client registration is very useful if client or resource or

Re: [OAUTH-WG] Oauth 2 and discovery

OK.  I'll do that.  Not hard.  Will folks want to discuss the individual submission here?  Or will that be in apps-discuss? Is it informational if it does IANA registry actions? Thanks, -bill > > From: Derek Atkins >To: William Mills >Cc: "oauth@ietf.or

Re: [OAUTH-WG] Oauth 2 and discovery

Hi, On Tue, June 12, 2012 7:19 pm, William Mills wrote: > If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there > relations defined for the OAuth endpoints  I had that in > http://tools.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, > but I've ripped all the discover

[OAUTH-WG] Oauth 2 and discovery

If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there relations defined for the OAuth endpoints  I had that in http://tools.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, but I've ripped all the discover stuff out of there. This seems more appropriate in the OAuth

Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

Hello, Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. Another typical case is that authorisation s

Re: [OAUTH-WG] On the OAuth Core Spec

Hi Derek, Hannes, Eran, Thanks, -sm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Is it workable/useful then to define something like:     basic_client_id = 1*basic_auth_allowed_characters     uri_client_id = 1*uri_allowed_characters And include text saying, "Clients using HTTP Basic authentication MUST have a client_id of type basic_client_id.  Clients using client_id of typ

Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that

[OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.   Does identifying the client with a URI allow some form of OpenID-ish flow for this?  Is the client ID as a URI a way to allow a trusted site to provi

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Frankly, I know of an OpenID Connect use case where it would really useful to be able to use URIs as client_id values, so the exclusion of colon (":") is unfortunate. (Some clients might want to use URIs with iOS custom schemas in some cases.) In this use case, the client_id would never be sent

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Encoding is an option which does not require us to address it. Those seeking to use URIs can simply specify that. However, Julian indicated earlier that this restriction in Basic may change, in which case we can reference Basic and simply add an interop warning (like the one we have for redirec

Re: [OAUTH-WG] On the OAuth Core Spec

Derek - Thank you for this note. It is very much appreacited. > From: Derek Atkins [mailto:de...@ihtfp.com] > Sent: Tuesday, June 12, 2012 10:28 AM > Having said that, are you still willing and able to be the editor of this > draft and > see it to its conclusion and publication? Yes. > If so,

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I agree that there is value in allowing the client_id to be a URI. The problem is that the ':' of the URI is not allowed in HTTP Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be documented and adds complex

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thin

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill's point in that regard. For instance, neither "scope" nor "error" allow non-ASCII characters. Julian, if you want different ABNF text than th

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth

[OAUTH-WG] On the OAuth Core Spec

Eran (and the rest of the OAuth WG), Hannes and I would like to apologize for what transpired last week with the publication of version 27 of the OAuth core specification. It was not our intention to get a document published behind your back, the goal was the get a document published in a more ti

Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated. On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer wrote: > I agree with Doug and George's reading: nuking the refresh token gets rid > of all access tokens ass

Re: [OAUTH-WG] New draft process / editor role

> Can we move forward with the work at hand now? I find your tone to be dismissive – which in general isn't in the spirit of moving things forward. Your comment on the MAC spec is tangential. Hannes never replied that Eran's request to wait for the ABNF was a problem nor to confirm Mike's ass

Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance. -- Justin On 06/11/2012 08:13 PM, doug foiles wrote: Hi Paul and George, Even th

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Mike Jones > Sent: Tuesday, June 12, 2012 6:17 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF > definitions > > Reviewing the feedback from

[OAUTH-WG] nits about definition of using form parameters

Hi there, re : This needs a normative reference to a spec that defines the application/x-www-form-urlencoded media type (such as ). Looking at the media ty

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

On 2012-06-12 00:16, Mike Jones wrote: Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's