Re: [OAUTH-WG] Possible alternative resolution to issue 26

Allowing URI requires allowing % encoding, which is workable.  As far as the protocol goes URI is a form of space separated string and the protocol doesn't care.  URI doesn't include quote or qhitespace in the allowed characters so there's no problem there. I agree that we'd have to write it su

Re: [OAUTH-WG] Proposed resolution for issue 26

I think James has made the case that there is an issue clear. As for what to pick, I favor not restricting scopes in the core spec, and clearly specifying the way scopes will be presented in HTTP headers in the bearer spec. For the later, James supplies a nice list of the alternatives. Personally

Re: [OAUTH-WG] Possible alternative resolution to issue 26

>> Existing practice is that simple ASCII strings like "email" "profile", >> "openid", etc. are used as scope elements.  Requiring them to be URIs >> would break most existing practice. > > Constraining syntax to an ascii token OR a URI (relative reference) might > work.  Anything with a colon can

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-05 at 05:07:06, Mike Jones wrote: > Existing practice is that simple ASCII strings like "email" "profile", > "openid", etc. are used as scope elements. Requiring them to be URIs > would break most existing practice. Constraining syntax to an ascii token OR a URI (relative reference)

[OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials

Although it seems like an abuse of the protocol, I'm wondering at Draft 22 as a mechanism for providing authorization without specifying client credentials (i.e. evaluating it as part of an SSO solution). Specifically, I'm referencing the scenario/flow in Section 4.3 ("Resource Owner Password

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On Tue, Oct 4, 2011 at 12:18 PM, Julian Reschke wrote: > On 2011-10-04 20:38, Marius Scurtescu wrote: >> >> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones > > wrote: >> >>    Existing practice is that simple ASCII strings like “email” >>    “profile”, “openid”, etc

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-04 20:38, Marius Scurtescu wrote: On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: Existing practice is that simple ASCII strings like “email” “profile”, “openid”, etc. are used as scope elements. Requiring them to be URIs would brea

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On Oct 4, 2011, at 2:38 PM, Marius Scurtescu wrote: > On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones > wrote: > Existing practice is that simple ASCII strings like “email” “profile”, > “openid”, etc. are used as scope elements. Requiring them to be URIs would > break most existing practice. > >

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones wrote: > Existing practice is that simple ASCII strings like “email” “profile”, > “openid”, etc. are used as scope elements. Requiring them to be URIs would > break most existing practice. > Aren't these simple strings URIs? I think they are parsed as

[OAUTH-WG] Phishing with Client Application Name Spoofing

I've not seen this particular variant of phishing and client impersonation discussed. A cursory search revealed that most of the related discussion centers around either (a) client impersonation with stolen client credentials or (b) phishing by malicious clients directing resource owners to spoofed

Re: [OAUTH-WG] Possible alternative resolution to issue 26

Existing practice is that simple ASCII strings like "email" "profile", "openid", etc. are used as scope elements. Requiring them to be URIs would break most existing practice. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...

Re: [OAUTH-WG] Possible alternative resolution to issue 26

I just realized that scopes are defined as a space separated list of strings, for some reason I though they are a list of URIs. Mark Lentczner just clarified for me that URIs are supposed to be ASCII only. IRIs can have non-ASCII characters and can be canonically converted to URIs using percent en

Re: [OAUTH-WG] Possible alternative resolution to issue 26

I very much agree with you there. As I said, simple roles are best and are by far the primary case. I'm just not so sure we should close the door. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-10-04, at 9:58 AM, William Mills wrote: > I don't believe that scope i

Re: [OAUTH-WG] Possible alternative resolution to issue 26

I don't believe that scope is the right place to carry a more complex grant, those would live in the token.  That would more logically go in the token.  XML gets weird when you get to the part about space separationoand order doesn't matter.  Scope's current definition makes it incompatible in s

Re: [OAUTH-WG] Possible alternative resolution to issue 26

In most cases, scope has just been a set of simple "roles" as in "readProfile", "updateStatus", etc. I tend to agree scope is an internal value that SHOULD never be seen by end-users (this should be made clear). The meaning of a scope must be conveyed in authorization dialog, the how of which i

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 10/03/2011 09:58 PM, William Mills wrote: You forgot: 4. Restrict the character set for scope to the point where these issues all go away. Assuming that this is *completely* internal, and no end users will ever see either of these, this seems like the most prudent if interoperability is

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-04 03:55, Mike Jones wrote: As editor, based upon James’ input, I’d like to expand the set of choices for the working group to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding are restricted to