Re: [OAUTH-WG] consistency of token param name in bearer token type

[Justin Richer]

The biggest problem that I can see are the examples and terminology in
the core doc, which tries very hard to not look like it is binding to
any particular use-a-token spec or token format. That plus the history
that George pointed out below (which I still very strongly believe that
'oauth_token' should not be used as that's been claimed by OAuth1) got
us here today. 

One of the downsides to splitting this into three specs is that we need
to be more consistent across them.

 -- Justin

On Wed, 2011-06-01 at 03:06 -0400, David Recordon wrote:
> Yeah, can understand how we got here. Just found it quite confusing
> when reading these two specifications together with an implementor's
> hat on.
> 
> On Tue, May 31, 2011 at 12:29 PM, George Fletcher  wrote:
> > Brief pointer to the "history" of this change. This change was adopted in
> > draft 4 of the bearer spec as there were concerns with the previous
> > parameter name of 'oauth_token'. The suggestion was made to use
> > 'bearer_token' so that it matches the scheme used in the Authorization
> > header. The thinking being that reading the bearer token spec would seem
> > weird if the Authorization header used one name and the GET/POST methods
> > used a different name.
> >
> > The 'bearer_token' name got a few +1 and no dissents.
> >
> > Full thread starts here [1]. Mike accepting the 'bearer_token'
> > recommendation is here [2].
> >
> > Thanks,
> > George
> >
> > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
> >
> > On 5/28/11 12:30 PM, David Recordon wrote:
> >
> > Did a full read through of draft 16 and the bear token spec with Paul
> > yesterday afternoon in order to do a manual diff from draft 10. The
> > point Doug raised was actually confusing. Throughout the core spec
> > it's referred to as access_token but then becomes bearer_token upon
> > use.
> >
> > Just thinking through this from a developer documentation perspective,
> > it's going to become confusing. Developer documentation focuses on
> > getting an access token and then using that access token to interact
> > with an API. Thus the code you're writing as a client developer will
> > use variables, cache keys, and database columns named `access_token`.
> > But then when you're going to use it, you'll need to put this access
> > token into a field named bearer_token.
> >
> > Feels quite a bit simpler to just name it access_token. Realize the
> > core spec never did this since we didn't want to trample on protected
> > resources which might already have a different type of access_token
> > parameter. oauth_token was a good compromise since developers would
> > already know that they were using OAuth and thus a new term wasn't
> > being introduced. That's no longer true with bearer_token since 99% of
> > developers will have never heard of a bearer token.
> >
> > Googling for "bearer token" turns up Eran's blog post titled "OAuth
> > Bearer Tokens are a Terrible Idea" and there isn't a single result on
> > the first page which explains what they are. Binging for "bearer
> > token" is equally scary.
> >
> > --David
> >
> >
> > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> >  wrote:
> >
> > The working group explicitly decided that a different name should be used,
> > to make it clear that other token types other than bearer tokens could also
> > be used with OAuth 2.
> >
> >
> >
> > -- Mike
> >
> >
> >
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> > Doug Tangren
> > Sent: Wednesday, May 11, 2011 10:09 PM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] consistency of token param name in bearer token type
> >
> >
> >
> > This may have come up before so I'm sorry if I'm repeating. Why does bearer
> > token spec introduce a new name for oauth2 access tokens [1],
> > "bearer_token", and before that [2], "oauth_token"?
> >
> >
> >
> > I apologize if this may sound shallow but, why introduce a new parameter
> > name verses sticking with what the general oauth2 spec already defines,
> > "access_token". It seems arbitrary for an auth server to hand a client an
> > apple then have the client hand it off to the resource server and call it an
> > orange.
> >
> >
> >
> > Was this just for the sake of differentiating the parameter name enough so
> > that the bearer tokens may be used in other protocols without being confused
> > with oauth2 access_tokens?
> >
> >
> >
> > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
> >
> > [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
> >
> >
> >
> > -Doug Tangren
> > http://lessis.me
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > h

Re: [OAUTH-WG] HTTP/1.0 and JSON

[Justin Richer]

> > I couldn't find a conclusion to the May 2010 discussions about using x-www-
> > form-urlencoded vs. json nor a rationale in the spec for using JSON. Why do 
> > I
> > need to add a JSON lexer/parser to my library just to get key-value pairs 
> > that
> > can be represented by form-urlencoded?
> 
> Every modern platform has a JSON parser.

While JSON is widespread, it is an additional requirement. I've done
some work to define and XML encoding for OAuth tokens here:

  http://tools.ietf.org/html/draft-richer-oauth-xml-00

The draft still needs to be updated to point to the right sections of
the OAuth2 spec, but the mechanics are still valid. 

The point of this is similar to your contention: if I'm already speaking
one wire format (XML), why would I want to deal with JSON just to do my
auth step? 

If you'd like to try defining a key-value encoding, we can publish an
extension draft for that as well.

 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] HTTP/1.0 and JSON

[Justin Richer]

On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote:
> On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer 
> wrote:
> >> > I couldn't find a conclusion to the May 2010 discussions about using
> >> > x-www-
> >> > form-urlencoded vs. json nor a rationale in the spec for using JSON.
> >> > Why do I
> >> > need to add a JSON lexer/parser to my library just to get key-value
> >> > pairs that
> >> > can be represented by form-urlencoded?
> >> 
> >> Every modern platform has a JSON parser.
> > 
> > While JSON is widespread, it is an additional requirement. I've done
> > some work to define and XML encoding for OAuth tokens here:
> > 
> >   http://tools.ietf.org/html/draft-richer-oauth-xml-00
> > 
> > The draft still needs to be updated to point to the right sections of
> > the OAuth2 spec, but the mechanics are still valid. 
> 
> Two queries on your spec:
>  - Have you considered using HTTP Accept: (content negotiation) rather than
> a 'format' parameter? Regardless I suggest using MIME types rather than
> 'json'/'xml'.

Yes, and I'm planning on putting that into the updated revision. I
already had someone yell at me about its omission. :) This will be in
addition to the format parameter, though, not in lieu of it. I also
greatly prefer short names in the parameter, especially because it's a
limited set. The Accept header will use mimetypes though, obviously. 

>  - Use Schema rather than typing by bespoke attributes?
> 
> It's a useful short-cut (as a consumer) to be able to apply a schema to
> validate the content including all of the values via basic schema
> types/regexp.
> Similarly with extensions, if you use namespacing then clients will
> transparently ignore anything that isn't in their recognised namespace(s).

I'm personally a fan of schema-by-fiat, which is what JSON does. I've
also always hated writing XML schemas. If, however, someone wants to
write a schema for the core components, I'd be fine with that. However,
I do want it to remain general enough to be able to encode more complex
extensions, and apart from saying all extensions are in some namespace,
I'm not sure how to handle that with a Schema. Speaking of namespaces...

> For simplicity I would require the default namespace (xmlns=) to be oauth.
> Then values can easily be extracted using string-matching in lightweight
> clients:
> $xml =~ /([^<]+)<\/access_token>/;

I avoided using a namespace specifically to cut down on verbosity, since
even a default namespace requires attributes in the root tag. While I
think string-matching like that in XML is a Very Bad Thing, I do want to
keep the serialization simple. That said, if there's enough of a call I
can put in a default namespace. What would the URI of that be?
http://oauth.net/2/xml? urn:oauth2:xml?

> (Schema would also address your 3.7 Information Loss because the Schema
> would explicitly define values as numeric or text and singular or multiple)

For core attributes, but not for encoding extensions. I wanted this to
be a ruleset that one could apply to a blob of JSON to translate it to
parseable XML.

> Lastly a general RFC point - should you reference RFC 3023, especially the
> content-type and security sections?

Good catch, thanks.

> > The point of this is similar to your contention: if I'm already speaking
> > one wire format (XML), why would I want to deal with JSON just to do my
> > auth step? 
> > 
> > If you'd like to try defining a key-value encoding, we can publish an
> > extension draft for that as well.
> 
> I think the simple case is simple:
> Content-type: application/x-www-form-urlencoded
> 
> access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8
> 
> I would re-use the OpenID scheme for providing extension data:
> 
> openid.ns.ax=http://openid.net/srv/ax/1.0&;
> openid.ax.type.email=http://schema.openid.net/contact/email&;
> openid.ax.value.email=t...@ecs.soton.ac.uk&
> oauth.ns.ext=http://example.com/api#limits&;
> oauth.ext.soft=1&
> oauth.ext.hard=15000&
> oauth.ns.rr=http://example.com/api#roles&;
> oauth.rr.role=owner&
> oauth.rr.role=editor&
> oauth.rr.role=creator&
> ...
> 
> I suggest a constraint that the form/urlencoded is always utf-8 (c.f.
> OpenURL KEV format NISO Z39.88-2004):
> Ë => %C3%8B
> And never:
> Ë => %CB

Not all OAuth extensions that return more stuff have a namespace,
though, so it's not an exact map. However, the general method of
encoding objects and lists could work.


> I'm happy to write this up but all I'd do is drop replacement text into
> your RFC.
> Do you have a source doc I can work on? What do I do with it when finished?

I'd be happy to incorporate your encoding if you want to write them up.

 -- Justin


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] consistency of token param name in bearer token type

[Justin Richer]

If we're changing the bearer token's name, are we going to change the
parameter name inside of MAC as well? At the moment, it's "id", which
I've always found an odd naming choice.

I would argue for consistency across the three main documents.

 -- Justin


On Thu, 2011-06-16 at 08:40 -0400, KIHARA, Boku wrote:
> +1 to access_token.
> 
> 2011/6/16 Eran Hammer-Lahav :
> > It should be pretty easy :-)
> >
> > Anyone objects to changing the parameter name from 'bearer_token' to 
> > 'access_token'? Let Mike know by 6/20 or he will make the change.
> >
> > EHL
> >
> >
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> >> Of Mike Jones
> >> Sent: Wednesday, June 01, 2011 1:15 PM
> >> To: David Recordon; George Fletcher
> >> Cc: paul Tarjan; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> >> type
> >>
> >> If you can drive a consensus decision for the name "access_token", I'd be
> >> glad to change the name in the spec.  I agree that the current names are
> >> confusing for developers.
> >>
> >>   -- Mike
> >>
> >> -Original Message-
> >> From: David Recordon [mailto:record...@gmail.com]
> >> Sent: Wednesday, June 01, 2011 12:06 AM
> >> To: George Fletcher
> >> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
> >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> >> type
> >>
> >> Yeah, can understand how we got here. Just found it quite confusing when
> >> reading these two specifications together with an implementor's hat on.
> >>
> >> On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
> >> wrote:
> >> > Brief pointer to the "history" of this change. This change was adopted
> >> > in draft 4 of the bearer spec as there were concerns with the previous
> >> > parameter name of 'oauth_token'. The suggestion was made to use
> >> > 'bearer_token' so that it matches the scheme used in the Authorization
> >> > header. The thinking being that reading the bearer token spec would
> >> > seem weird if the Authorization header used one name and the GET/POST
> >> > methods used a different name.
> >> >
> >> > The 'bearer_token' name got a few +1 and no dissents.
> >> >
> >> > Full thread starts here [1]. Mike accepting the 'bearer_token'
> >> > recommendation is here [2].
> >> >
> >> > Thanks,
> >> > George
> >> >
> >> > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> >> > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
> >> >
> >> > On 5/28/11 12:30 PM, David Recordon wrote:
> >> >
> >> > Did a full read through of draft 16 and the bear token spec with Paul
> >> > yesterday afternoon in order to do a manual diff from draft 10. The
> >> > point Doug raised was actually confusing. Throughout the core spec
> >> > it's referred to as access_token but then becomes bearer_token upon
> >> > use.
> >> >
> >> > Just thinking through this from a developer documentation perspective,
> >> > it's going to become confusing. Developer documentation focuses on
> >> > getting an access token and then using that access token to interact
> >> > with an API. Thus the code you're writing as a client developer will
> >> > use variables, cache keys, and database columns named `access_token`.
> >> > But then when you're going to use it, you'll need to put this access
> >> > token into a field named bearer_token.
> >> >
> >> > Feels quite a bit simpler to just name it access_token. Realize the
> >> > core spec never did this since we didn't want to trample on protected
> >> > resources which might already have a different type of access_token
> >> > parameter. oauth_token was a good compromise since developers would
> >> > already know that they were using OAuth and thus a new term wasn't
> >> > being introduced. That's no longer true with bearer_token since 99% of
> >> > developers will have never heard of a bearer token.
> >> >
> >> > Googling for "bearer token" turns up Eran's blog post titled "OAuth
> >> > Bearer Tokens are a Terrible Idea" and there isn't a single result on
> >> > the first page which explains what they are. Binging for "bearer
> >> > token" is equally scary.
> >> >
> >> > --David
> >> >
> >> >
> >> > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> >> >  wrote:
> >> >
> >> > The working group explicitly decided that a different name should be
> >> > used, to make it clear that other token types other than bearer tokens
> >> > could also be used with OAuth 2.
> >> >
> >> >
> >> >
> >> > -- Mike
> >> >
> >> >
> >> >
> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> >> > Of Doug Tangren
> >> > Sent: Wednesday, May 11, 2011 10:09 PM
> >> > To: oauth@ietf.org
> >> > Subject: [OAUTH-WG] consistency of token param name in bearer token
> >> > type
> >> >
> >> >
> >> >
> >> > This may have come up before so I'm sorry if I'm repeatin

Re: [OAUTH-WG] Client authentication requirement

[Justin Richer]

Agree with Torsten -- I would hate for us to repeat the
"anonymous/anonymous" thing that Google implemented for OAuth1.

 -- Justin

On Thu, 2011-06-16 at 15:42 -0400, Torsten Lodderstedt wrote:
> -1 making client authentication required at the access token endpoint
> 
> Client authentication is useful in some situations to raise the security 
> level. But requiring it will either keep out native apps or force there 
> developers to use useless/insecure secrets (I would call this "pseudo 
> security").
> 
> +1 making the client authentication required for certain client types.
> 
> for a definition of client types and there respective security 
> properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10
> 
> In my opinion, the security considerations section already gives a clear 
> guideline when client authentication should be used and when the authz 
> server should rely on other mechanims.
> 
> regards,
> Torsten.
> 
> Am 16.06.2011 17:08, schrieb Thomas Hardjono:
> > Apologies for the late response.
> >
> >
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> >> Of Eran Hammer-Lahav
> >> Sent: Wednesday, June 15, 2011 1:27 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] Client authentication requirement
> >>
> >> Client authentication has been one of the main problem areas in OAuth
> >> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
> >> confusing).
> >>
> >> Because of the desire to allow any client type in any deployment
> >> environment, we ended up with a barely defined client authentication
> >> model. We offer password-based client authentication using HTTP Basic
> >> (and an alternative parameter), but leave it optional.
> > I would to suggest that perhaps we need a better definition of the "client" 
> > by way of identifying one or two (or three) types of clients and listing 
> > their respective security properties/capabilities. For example, if a client 
> > can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a 
> > client can do TLS but cannot do proper X509 processing, then list this, 
> > etc. etc.
> >
> > In this way developers can at least map (in the minds) which client type 
> > matches their deployment scenario, based on the best-match capabilities 
> > list.
> >
> >
> >> I would like to go back to requiring client authentication for the
> >> access token endpoint, using HTTP Basic or other schemes. To leave the
> >> door open for clients incapable of authenticating to use the endpoint,
> >> we will add a security consideration section discussing the
> >> ramifications of using the access token endpoint without client
> >> authentication.
> >>
> >> This suggestions is linked to the topic of refresh tokens which I'll
> >> post separately.
> >>
> >> EHL
> > +1 agree that client authentication (to access token endpoint) should be 
> > made a requirement.
> >
> > /thomas/
> >
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client authentication requirement

[Justin Richer]

> > Certainly not. Are we discussing to make client
> > authentication required just for syntactical purposes? 
> > 
> > That is what I'd like to see.
> > 
> > 
> > From my perspective, no harm is done by making client authentication
> > a syntactical requirement of the protocol.
> > 
> > 
> > - clients that can't keep secrets aren't harmed; they have the exact
> > same security they do today.
> > - everyone else benefits because the spec becomes simpler and more
> > consistent.
> 
> No, it's not simpler nor clearer. Such a client secret is useless, so
> the security implications have to be explained anyway. Moreover,
> whatever the spec will state people would start to _rely_ on client
> secrets even for native apps, which is a really bad idea.

Not only does it give the wrong impression for developers using this, it
forces client developers to use a pattern that doesn't make sense. I
really don't like the approach of "if you're not going to really use
this, then use this well-known dummy value instead." I'd rather have the
useless bits simply not sent instead of filled in with nonsense values. 

This is getting back to the one-size-fits-all OAuth 1.0 approach that we
were trying to get *away* from here. At least, I thought we were.

 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] issuing multiple tokens

[Justin Richer]

I completely agree that the single-token case needs to be left alone, 
and I rather like this idea. The AS would return something like:


{
 access_token: [
{
  access_token: "1234656",
  expires_in: 3600,
  token_type: bearer
},
{
  access_token: "abcdefg",
  expires_in: 3600,
  token_type: MAC,
  mac_stuff: "goes_here"
}
  ],
  token_type: multiple
}

This would not only let clients who are doing the common one-token flow 
ignore the "multiple" token type, it would also allow for re-use of 
token storage libraries for the inner token bits. And you could go crazy 
and pass a multiple token full of multiple tokens, too. It's turtles all 
the way down!


 -- Justin

On 6/16/2011 7:23 PM, William J. Mills wrote:
Probably defining a token type of "multiple_tokens" would be my 
preference, and if you get that back then you have to parse an array 
of {type, token}*.  What that array looks like could be JSON in the 
payload, or something else.  That leaves the single token use case alone.



*From:* Eran Hammer-Lahav 
*To:* Phil Hunt ; "Manger, James H" 


*Cc:* OAuth WG 
*Sent:* Wednesday, June 15, 2011 10:46 PM
*Subject:* Re: [OAUTH-WG] issuing multiple tokens

It is not an important enough feature. Parsing an array response when 
99.99% will be a single object array is annoying. Also, what would you 
return in case of error? A single object? What is the client supposed 
to do if it gets an empty array? Array with more than one token?


*This* would be the hack... If this is something people want to 
deploy, a full proposal end-to-end is required. And not now.


EHL


> -Original Message-
> From: oauth-boun...@ietf.org  
[mailto:oauth-boun...@ietf.org ] On Behalf

> Of Phil Hunt
> Sent: Wednesday, June 15, 2011 10:40 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>
> +1
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.h...@oracle.com 
>
>
>
>
>
> On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>
> > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg 
said +1

> to that; John Bradley identified that OpenID Connect needs to request
> multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
> something that could make sense; ...
> >
> > Issuing 0, 1 or more tokens looks like an important enough feature 
to fix

> now, instead of trying to hack it in after the spec is finalised.
> >
> >
> > Changing the access token response [5.1] to be a JSON array of JSON
> objects (one JSON object per issued token) seems like a simple way 
to get
> this important functionality -- with very limited overhead for 
services that will
> only ever issue a single token, and client written just for those 
services.

> >
> > P.S. Does Facebook return a JSON object for its access token 
response (as

> in draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded
> as the example at http://developers.facebook.com/docs/authentication/
> implies [4th screen shot down]?
> >
> > --
> > James Manger
> >
> >
> > Eran said (on a different thread):
> >
> > ...if the client can authenticate with the authorization server. 
Why not just
> include the client identifier and user identifier and let the 
authorization

> server lookup what the user already authorized?
> >
> >
> > Igor Faynberg wrote:
> >
> > +1
> >
> > Torsten Lodderstedt wrote:
> >> Hi,
> >>
> >> I also see the need to request and issue multiple tokens in a single
> >> authorization process. There has already been some discussion about
> >> this topic roughly a year ago:
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> >>
> >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
> >> supporting that use case. It's called "bulk authorization".
> >>
> >> Would that be an interessting topic we could discuss at IETF-81 for
> >> the re-chartering?  I could present our approach there.
> >>
> >> regards,
> >> Torsten.
> >
> >> Am 10.06.2011 21:08, schrieb John Bradley:
> >>> We have identified the need to request multiple tokens as one issue
> >>> that we would have to extend.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai

Re: [OAUTH-WG] issuing multiple tokens

[Justin Richer]

Incidentally, I'd like to clarify my position that the below or any 
other kind of multi-token formatting doesn't belong in the core spec.


 -- Justin

On 6/17/2011 9:46 AM, Justin Richer wrote:
I completely agree that the single-token case needs to be left alone, 
and I rather like this idea. The AS would return something like:


{
 access_token: [
{
  access_token: "1234656",
  expires_in: 3600,
  token_type: bearer
},
{
  access_token: "abcdefg",
  expires_in: 3600,
  token_type: MAC,
  mac_stuff: "goes_here"
}
  ],
  token_type: multiple
}

This would not only let clients who are doing the common one-token 
flow ignore the "multiple" token type, it would also allow for re-use 
of token storage libraries for the inner token bits. And you could go 
crazy and pass a multiple token full of multiple tokens, too. It's 
turtles all the way down!


 -- Justin

On 6/16/2011 7:23 PM, William J. Mills wrote:
Probably defining a token type of "multiple_tokens" would be my 
preference, and if you get that back then you have to parse an array 
of {type, token}*.  What that array looks like could be JSON in the 
payload, or something else.  That leaves the single token use case alone.



*From:* Eran Hammer-Lahav 
*To:* Phil Hunt ; "Manger, James H" 


*Cc:* OAuth WG 
*Sent:* Wednesday, June 15, 2011 10:46 PM
*Subject:* Re: [OAUTH-WG] issuing multiple tokens

It is not an important enough feature. Parsing an array response when 
99.99% will be a single object array is annoying. Also, what would 
you return in case of error? A single object? What is the client 
supposed to do if it gets an empty array? Array with more than one token?


*This* would be the hack... If this is something people want to 
deploy, a full proposal end-to-end is required. And not now.


EHL


> -Original Message-
> From: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] On Behalf

> Of Phil Hunt
> Sent: Wednesday, June 15, 2011 10:40 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>
> +1
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.h...@oracle.com <mailto:phil.h...@oracle.com>
>
>
>
>
>
> On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>
> > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg 
said +1

> to that; John Bradley identified that OpenID Connect needs to request
> multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
> something that could make sense; ...
> >
> > Issuing 0, 1 or more tokens looks like an important enough 
feature to fix

> now, instead of trying to hack it in after the spec is finalised.
> >
> >
> > Changing the access token response [5.1] to be a JSON array of JSON
> objects (one JSON object per issued token) seems like a simple way 
to get
> this important functionality -- with very limited overhead for 
services that will
> only ever issue a single token, and client written just for those 
services.

> >
> > P.S. Does Facebook return a JSON object for its access token 
response (as
> in draft-ietf-oauth-v2-12 that they reference), or 
x-www-form-urlencoded

> as the example at http://developers.facebook.com/docs/authentication/
> implies [4th screen shot down]?
> >
> > --
> > James Manger
> >
> >
> > Eran said (on a different thread):
> >
> > ...if the client can authenticate with the authorization server. 
Why not just
> include the client identifier and user identifier and let the 
authorization

> server lookup what the user already authorized?
> >
> >
> > Igor Faynberg wrote:
> >
> > +1
> >
> > Torsten Lodderstedt wrote:
> >> Hi,
> >>
> >> I also see the need to request and issue multiple tokens in a single
> >> authorization process. There has already been some discussion about
> >> this topic roughly a year ago:
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> >>
> >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
> >> supporting that use case. It's called "bulk authorization".
> >>
> >> Would that be an interessting topic we could discuss at IETF-81 for
> >> the re-chartering?  I could present our approach there.
> >>
> >> regards,
> >> Torsten.
> >
> >> Am 10.06.2011 21:08, schrie

Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?

[Justin Richer]

Eve,

We've been using (and contributing some to) the implementation in
SpringSecurity:

  http://static.springsource.org/spring-security/oauth/

I don't have a good list otherwise, though I'd be interested in seeing
the results as well.

To Eran: I really don't get your comment. Libraries are a very Good
Thing and their use and development should be greatly encouraged by the
OAuth community. The less that I have to write the Same Code As Last
Time the better. 

 -- Justin

On Fri, 2011-06-24 at 13:02 -0400, Eve Maler wrote:
> Zero response from the other list. Any suggestions from folks here?
> 
> Begin forwarded message:
> 
> > From: Eve Maler 
> > Date: 20 June 2011 4:54:56 PM PDT
> > To: oa...@googlegroups.com
> > Subject: [oauth] Good list of OAuth open source?
> > Reply-To: oa...@googlegroups.com
> > 
> > The list at http://oauth.net/code/ seems really random and out of date. 
> > Does anyone have a current list of open-source software that supports 
> > OAuth, including drafts of 2.0?
> > 
> > Thanks,
> > 
> > Eve
> 
> 
> Eve Maler  http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback

[Justin Richer]

The OpenID Connect folks have been using Simple Web Discovery, which is
as I understand it a rough translation of XRD into JSON, with a couple
of simplifying changes. (Mike, want to throw your hat in on this one?)

http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

 -- Justin

On Mon, 2011-07-04 at 00:27 -0400, Eve Maler wrote:
> FWIW, the "Dynamic OAuth Client Registration" proposal made by the
> User-Managed Access folks:
> 
> 
> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
> 
> 
> ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based
> UMA protocol itself:
> 
> 
> http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt
> 
> 
> We'd be just as happy to use a JSON-based version of XRD if it can be
> standardized, and we did do some experimentation with this early on.
> But because XRD 1.0 is now stable and is straightforward enough to use
> for our needs, we decided to use it normatively for now. The UMA
> implementation used by http://smartam.net implements this today and it
> works fine.
> 
> 
> Eve
> 
> On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote:
> 
> > Hannes,
> > 
> > 
> > None of the current OAuth WG document address discovery in any way,
> > so clearly there will be no use of XRD. But the OAuth community
> > predating the IETF had multiple proposals for it. In addition,
> > multiple times on the IETF OAuth WG list, people have suggested
> > using host-meta and XRD for discovery purposes.
> > 
> > 
> > The idea that XRD was reused without merit is both misleading and
> > mean-spirited. Personally, I'm sick of it, especially coming from
> > standards professionals.
> > 
> > 
> > XRD was largely developed by the same people who worked on
> > host-meta. XRD predated host-meta and was designed to cover the
> > wider use case. Host-meta was an important use case when developing
> > XRD in its final few months. It was done in OASIS out of respect to
> > proper standards process in which the body that originated a work
> > (XRDS) gets to keep it.
> > 
> > 
> > I challenge anyone to find any faults with the IPR policy or process
> > used to develop host-meta in OASIS.
> > 
> > 
> > XRD is one of the simplest XML formats I have seen. I bet most of
> > the people bashing it now have never bothered to read it. At least
> > some of these people have been personally invited by me to comment
> > on XRD while it was still in development and chose to dismiss it.
> > 
> > 
> > XRD was designed in a very open process with plenty of community
> > feedback and it was significantly simplified based on that feedback.
> > In addition, host-meta further simplifies it by profiling it down,
> > removing some of the more complex elements like Subject and Alias
> > (which are very useful in other contexts). XRD is nothing more than
> > a cleaner version of HTML  elements with literally a handful
> > of new elements based on well defined and widely supported
> > requirements. It's entire semantic meaning is based on the IETF Link
> > relation registry RFC.
> > 
> > 
> > There is something very disturbing going on these days in how people
> > treat XML-based formats, especially form OASIS.
> > 
> > 
> > When host-meta's predecessor - side–meta – was originally proposed a
> > few years ago, Mark Nottingham proposed an XML format not that
> > different from XRD. There is nothing wrong with JSON taking over as
> > a simpler alternative. I personally prefer JSON much better. But it
> > would be reckless and counter productive to ignore a decade of work
> > on XML formats just because it is no longer cool. Feels like we back
> > in high school.
> > 
> > 
> > If you have technical arguments against host-meta, please share. But
> > if your objections are based on changing trends, dislike of XML or
> > anything OASIS, grow up.
> > 
> > 
> > EHL
> > 
> > 
> > 
> > 
> > 
> > 
> > From: Hannes Tschofenig 
> > Date: Sun, 3 Jul 2011 00:36:29 -0700
> > To: Mark Nottingham 
> > Cc: Hannes Tschofenig , "i...@ietf.org
> > IETF" , Eran Hammer-lahav ,
> > oauth WG 
> > Subject: Re: Second Last Call:  (Web
> > Host Metadata) to Proposed Standard -- feedback
> > 
> > 
> > 
> > > I also never really understood why XRD was re-used. 
> > > 
> > > 
> > > Btw, XRD is not used by any of the current OAuth WG documents, see
> > > http://datatracker.ietf.org/wg/oauth/
> > > 
> > > 
> > > 
> > > 
> > > On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:
> > > 
> > > 
> > > > * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth.
> > > > Maybe I'm just scarred by WS-*, but it seems very
> > > > over-engineered for what it does. I understand that the
> > > > communities had reasons for using it to leverage an existing
> > > > user base for their specific user cases, but I don't see any
> > > > reason to generalise such a beast into a generic mechanism.
> > > 
> > > 
> > > 
> > > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.

Re: [OAUTH-WG] Concerns about Implicit Grant flow

[Justin Richer]

You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light clients
with limited lifespans, and it's a tradeoff between security, ease of
implementation, and performance.

 -- Justin

On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote:
> Hello!
> 
> 
> Foursquare recently encountered a scary example of a client
> accidentally leaking user tokens as part of the implicit grant flow.
> It turns out the official "Tweet this" button provided by twitter
> grabs the URL, including fragment, at the time of page load, before
> the client's Javascript has had a chance to elide the access_token
> hash value. And it's easy to imagine lots of other sharing and
> analytics tools could be similarly aggressive in transmitting hash
> values outside of the page.
> 
> 
> We've thought a lot about what to do about this, short of disabling
> the flow entirely. One thing that seems viable is to make the "access
> token" in this flow actually a one-time use token. The requesting page
> would then make a JSONP request exchanging the one-time use token for
> a permanent token that is never visible in the URL. Has this come up?
> Have you had any feedback from other implementors?
> 
> 
> We're not excited about such a blatant deviation from the spec, but
> we're not sure what else to do.
> 
> 
> Cheers,
> Kushal


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Concerns about Implicit Grant flow

[Justin Richer]

> 
> - give out authorization codes via the user-agent flow.  We've
> implemented a variation of this based on HTML5 and window.postMessage.
> 
Caveat: This will run you off-spec.

> - use a fixed callback URL for the user-agent flow.  Make sure that
> fixed callback URL does not run random bits of script.  Then have that
> fixed callback URL use javascript to convey the token to other pages
> on the same origin.
>
> It's a bad idea to use the user-agent flow without a specific
> whitelist of callback URLs which can receive the token.

Brian's nailed it here. The best way to use this flow is to control the
landing page as much as possible.

 -- Justin


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization code security considerations

[Justin Richer]

I'm not sure normative language even fits here. We need something like 
"Authorization codes should be treated as sensitive and the client needs 
to try to make sure it doesn't leak the authorization code." But more 
formal and less garden pathy than I'm able to pen at the moment.

  -- Justin

On 7/8/2011 2:39 PM, Eran Hammer-Lahav wrote:

"Authorization codes MUST be kept confidential"

How exactly? They are not confidential by nature, being received via 
redirection in the URI query. I know what this sentence is trying to accomplish 
but not sure how to do that with normative language. SHOULD doesn't really work 
here either.

Suggestions?

EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Issue 15, new client registration

[Justin Richer]

I would avoid using the term "open" here as it has other deep-seated
meanings in the software world, particularly with regard to Open Source
and Open Standard stuff. FWIW, I think "confidential/public" or
"private/public" are serviceable.

 -- Justin

On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-Lahav wrote:
> How about confidential/open?
> 
> EHL
> 
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Friday, July 22, 2011 2:12 PM
> > To: Torsten Lodderstedt; OAuth WG
> > Subject: Re: [OAUTH-WG] Issue 15, new client registration
> > 
> > 
> > 
> > > -Original Message-
> > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > > Of Torsten Lodderstedt
> > > Sent: Wednesday, July 20, 2011 1:59 PM
> > > To: OAuth WG
> > > Subject: Re: [OAUTH-WG] Issue 15, new client registration
> > >
> > > 2.1 Client types
> > >
> > > I'm struggeling with the new terminology of "private" and "public"
> > > clients. In my perception, the text just distinguishes clients which
> > > can be authenticated and such which cannot. This is fine but I
> > > consider the wording misleading. I would suggest to change it to
> > > something like trusted/untrusted or authenticated/unauthenticated or
> > Verifiable/Forgeable.
> > 
> > I'm open to changing the names.
> > 
> > I don't like trusted/untrusted because OAuth does not define trust. The
> > authenticated/unauthenticated pair is also not ideal because the terms
> > describe the outcome, not the nature of the client. As for
> > verifiable/forgeable, I think these terms are too complicated for a casual
> > reader.
> > 
> > My intention with public/private is to identify the nature of the client
> > credentials. So a more verbose version would be 'public credentials/private
> > credentials'. This also works with 'code' instead of 'credentials'.
> > 
> > It's clear from the past year of discussions that we need terminology to
> > describe these two types.
> > 
> > Any other suggestions?
> > 
> > EHL
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Justin Richer]

Isn't this what section 1.5 is already there for? 

   Refresh tokens are credentials used to obtain access tokens.  Refresh
   tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner).  Issuing a refresh token is optional and is included when
   issuing an access token.

   A refresh token is a string representing the authorization granted to
   the client by the resource owner.  The string is usually opaque to
   the client.  The token denotes an identifier used to retrieve the
   authorization information.  Unlike access tokens, refresh tokens are
   intended for use only with authorization servers and are never sent
   to resource servers.

What could make this text clearer? 

(Though while I'm here, I just noticed a nit: 
  "Issuing a refresh token is optional and is included when issuing an
access token." 

Could be clearer, as in something like: 

 "Issuing a refresh token is optional, but when one is issued it is
included along with an access token.")

 -- Justin

On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote:
> Does it want to be in the main definition or the security
> considerations section?
> 
> 
> 
> 
> __
> From: Anthony Nadalin 
> To: Dick Hardt 
> Cc: "OAuth WG (oauth@ietf.org)" 
> Sent: Thursday, August 11, 2011 11:15 AM
> Subject: Re: [OAUTH-WG] Refresh Tokens
> 
> Many reasons, but none are explained in the specification
>  
> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
> Sent: Thursday, August 11, 2011 10:51 AM
> To: Anthony Nadalin
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> My recollection of refresh tokens was for security and revocation.
>  
> security: By having a short lived access token, a compromised access
> token would limit the time an attacker would have access
>  
> revocation: if the access token is self contained, authorization can
> be revoked by not issuing new access tokens. A resource does not need
> to query the authorization server to see if the access token is
> valid.This simplifies access token validation and makes it easier to
> scale and support multiple authorization servers.  There is a window
> of time when an access token is valid, but authorization is revoked. 
>  
>  
>  
> On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:
> 
> 
> 
> Nowhere in the specification is there explanation for refresh tokens,
> The reason that the Refresh token was introduced was for anonymity.
> The scenario is that a client asks the user for access. The user wants
> to grant the access but not tell the client the user's identity. By
> issuing the refresh token as an 'identifier' for the user (as well as
> other context data like the resource) it's possible now to let the
> client get access without revealing anything about the user. Recommend
> that the above explanation be included so developers understand why
> the refresh tokens are there.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Draft 20 last call comments

[Justin Richer]

In addition to taking another read through the document myself, I asked
another developer here to give it a once over. She's never implemented
an OAuth client or server, but has knowledge of what it's for. Thus, an
experienced developer new to building with OAuth2 -- a key target
audience for these documents.

As you'll see here, most of our qualms are in the front matter of the
document. The actually gritty technical implementation details are
pretty solid at this point.

1.2/1.4: The term "authorization grant" remains confusing and the
introduction is riddled with jargon like "intermediate credential". With
the diagram in 1.2, it appears to be an explicit technological
underpinning of the protocol flow instead of a general conceptual
construct that is used in several different ways. Basically, what
"authorization grant" *means* is not obvious within this document.
Section 4 makes much more sense than the introduction text does here.
Perhaps we should just replace most of 1.4 with just the introductory
text to 4 (perhaps slightly expanded), and then a reference to the
sub-parts of section 4 for the meat of the concept (and in the process,
nix the subsections of 1.4 entirely).

1.2(B): "Provided" is wrong here (it implies a direct hand-over), and
the last sentence is awkward. Suggest reword to: 
The client receives an authorization grant which represents the
authorization granted by the resource owner.  The type of 
authorization grant is dependent on which methods are supported
by both the client and authorization server.

1.3/1.4/1.5: Consider switching order to Authorization Grant, Access
Token, Refresh Token

1.4.1: We probably want to mention a user agent here in the exposure
risk at the end. Since that's really the problem -- the browser could
steal the token, not the end user.

1.4.2: Still don't like the term "implicit". It's misleading. Even
"direct authorization" would be better, though still not ideal.

1.4.5: Throw a simple reference to 8.3 here?

2: Isn't "means" generally treated as singular in instances like this?
Thus "means ... is" instead of "means ... are".

2.1/2.2: The requirements (2.2) should go first in section 2. The client
types are part of deciding the requirements, and the concepts flow
better this way.

2.1: I like the calling out of the types of clients, it helps cement
things.

2.3: Suggest renaming to "Client Identification" to parallel "Client
Authentication" in 2.4

2.3: Should "... cannot be used alone" be made into a normative, as "...
MUST NOT be used alone"?

2.4.2: Want to mention the MAC binding as an example here? This would
parallel the OAuth2 method of signing the fetch for a request token more
directly.

3. Authorization endpoint's "used to obtain authorization from" should
be "used to obtain an authorization grant from", to be parallel with the
token endpoint description.


 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Bearer Token Last Call Comments

[Justin Richer]

1.3: This draft still uses the term "access grant" where the core now
uses "authorization grant". Change all references to "authorization
grant" and reference section 1.4 in core. Also, too many parenthetical
statements in opening paragraph -- suggested rewrite of this bit: 
Before a client can access a protected resource, it must first 
obtain an authorization grant [[link to core S.1.4]] from the 
resource owner, and then exchange the authorization grant for 
an access token. The access token then represents the scope, 
duration, and other access attributes granted by the 
authorization grant.

2: "...SHOULD NOT be used unless no other..." is a triple negative and
while technically correct it is a bit head-spinny to read. Suggested
rewrite: "Due to the Security Considerations (S.3) associated with the
URI method, this method SHOULD NOT be used unless it is the only
feasible method."

2.1/2.2/2.3: Introductory text is non-parallel. Suggest changing intro
to 2.1 to parallel 2.2 and 2.3, with a "When including the access token
in the Authorization header, the client ..." construct.

2.2: "unless the following conditions are met" is ambiguous. All
conditions are met? At least one?

2.3: Are there conditions for this use as well, to match 2.2?

2.2/2.3: Add normative language to: "The entity-body MAY include other
request specific parameters. In which case..." (similar in 2.3's request
URI) Might be useful to have the example show an additional parameter.

2.4: Should this be a top-level section? Since it's dealing with the
from-the-server bit instead of the to-the-server bit that the rest of 2.
is dealing with.

3.1: Missing word: "Token redirect:  An attacker uses the token
generated for consumption by [one] resource server to obtain access to
another resource server."

3: There's a mix of normative and non-normative language throughout this
section, as well as a mix of imperative and descriptive language. We
suggest making the whole section normative and imperative to be
consistent. Particular instances:

  3.2: "the lifetime of the token MUST be limited”

  3.3: validate SSL certificate chains: "The client MUST..."

  3.3: issue short lived bearer tokens: Change to something like "Token 
servers SHOULD issue short-lived (one hour or less) bearer 
tokens, particularly when issuing tokens to clients that run 
within a web browser or other environments where information 
leakage may occur. Using short-lived bearer tokens can reduce 
the impact of one of them being leaked."

  3.3: scoped bearer tokens: "Token servers SHOULD issue bearer tokens 
that contain an audience restriction..."

  3.3: don't pass: "Bearer tokens SHOULD NOT be passed in page URLs 
(for example as query string parameters). Instead, bearer 
tokens SHOULD be passed in HTTP message headers or message 
bodies for which confidentiality measures are taken. Browsers, 
web servers, and other software may not adequately secure URLs 
in the browser history, web server logs, and other data 
structures. If bearer tokens are passed in page URLs, attackers 
might be able to steal them from the history data, logs, or 
other unsecured locations."



 -- Justin Richer

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] MAC Token Comments

[Justin Richer]

2: MAC Key: "The server MUST NOT reissue a previously issued MAC key and
MAC key identifier combination." 

3: I would still like to see a binding for post body and url parameters.
This could be as simple as defining a set of parameter names for
everything used in the auth header, but I'm still given the impression
that this has been deemed outside the scope of the MAC token. Our use
case is to pass around signed URLs between servers with all query
parameters protected by the signature, which we use 2-legged OAuth 1.0
for today. We can try to get language for this together if there's
enough draw for it, but I haven't been hearing that from other folks yet
so we might just try to draft an extension to the extension, instead.

5: This section's wording should be brought more in line with the
descriptions of the OAuth protocol in both core and bearer, which in
turn should actually be a bit closer together themselves. Seems like we
need a succinct elevator pitch for "what is OAuth2" to drop into all of
these locations (and other extension specs) -- anybody want to take a
crack at distilling one from these three sources?

7.9: Grammar tweak: "Those designing additional methods should evaluate 
the compatibility of the normalized request string with their 
    own security requirements."


 -- Justin Richer

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS 1.2

[Justin Richer]

As I recall, the logic of the group here was something like:

"We want transport-layer encryption, so let's grab the latest version of
that around, which looks to be TLS 1.2"

With that logic in mind, this relaxation makes sense to me. Does anyone
remember this requirement differently?

 -- Justin 
(who admittedly couldn't tell the difference between SSL and TLS)

On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote:
> I wanted to follow up on this and see if there was any consideration to 
> relaxing this requirement. Can someone actually point me to a compliant 
> implementation using TLS 1.2 because after looking at a number of them, 
> I have yet to find one that does.
> 
> Rob
> 
> On 8/12/11 3:56 PM, Rob Richards wrote:
> > The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based 
> > on a thread about this from last year I was under the impression that 
> > it was going to be relaxed to a SHOULD with most likely TLS 1.0 (or 
> > posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require 
> > 1.2 when many systems out there can't support it. IMO this is going to 
> > be a big stumbling block for people to implement a compliant OAuth 
> > system. Even PCI doesn't require 1.2.
> >
> > Rob
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 20 last call comments

[Justin Richer]

Comments inline.

On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote:
> Thanks for the feedback.
> 
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Justin Richer
> > Sent: Thursday, August 11, 2011 2:07 PM
> 
> > 1.2/1.4: The term "authorization grant" remains confusing and the
> > introduction is riddled with jargon like "intermediate credential". With the
> > diagram in 1.2, it appears to be an explicit technological underpinning of 
> > the
> > protocol flow instead of a general conceptual construct that is used in 
> > several
> > different ways. Basically, what "authorization grant" *means* is not obvious
> > within this document.
> >
> > Section 4 makes much more sense than the introduction text does here.
> > Perhaps we should just replace most of 1.4 with just the introductory text 
> > to
> > 4 (perhaps slightly expanded), and then a reference to the sub-parts of
> > section 4 for the meat of the concept (and in the process, nix the 
> > subsections
> > of 1.4 entirely).
> > 
> > 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the 
> > last
> > sentence is awkward. Suggest reword to:
> > The client receives an authorization grant which represents the
> > authorization granted by the resource owner.  The type of
> > authorization grant is dependent on which methods are supported
> > by both the client and authorization server.
> 
> Change (B) in 1.2 to:
> 
>   The client receives an authorization grant which is a 
> credential representing
>   the resource owner's authorization, expressed using one of four 
> grant types defined
>   in this specification or using an extension grant type. The 
> authorization grant type
>   depends on the method used by the client to request 
> authorization and the types
>   supported by the authorization server.
>
> And changed 1.4 to:
> 
>   An authorization grant is a credential representing the resource 
> owner's authorization
>   (to access its protected resources) used by the client to obtain an 
> access token. This
>   specification defines four grant types: authorization code, 
> implicit, resource owner
>   password credentials, and client credentials, as well as an 
> extensibility mechanism for
>   defining additional types.

Much better for both overall though.


> > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
> > Refresh Token
> 
> Not sure. What do others think? I put access token first because it is a more 
> important term to get out of the way.

I agree that access tokens are a more important topic to OAuth overall,
but the rest of the document presents things in protocol flow order: you
get the auth grant, then you get the tokens.

> > 1.4.1: We probably want to mention a user agent here in the exposure risk at
> > the end. Since that's really the problem -- the browser could steal the 
> > token,
> > not the end user.
> 
> Proposed text?

   The authorization code provides a few important security benefits
   such as the ability to authenticate the client and issuing the access
   token directly to the client without potentially exposing it to
   others, including the resource owner or other applications in the resource
   owner's user agent.

(Still not good wording... but the idea is to point out that you the
leak possibility here stems from using the front channel.)

> > 1.4.2: Still don't like the term "implicit". It's misleading. Even "direct
> > authorization" would be better, though still not ideal.
> 
> It's the best we've got. "Direct authorization" is not a grant type, but a 
> flow description.

Fair enough. I shall remain a conscientious objector. :)

> > 1.4.5: Throw a simple reference to 8.3 here?
> 
> No forward references whenever possible.

Fair style point, but I think this one is worth it. This is why our
documents have hyperlinks.



For each of 1.4.x, I'd still rather see the 1.4.x sections just go away.



> > 2: Isn't "means" generally treated as singular in instances like this?
> > Thus "means ... is" instead of "means ... are".
> 
> Don't know.

I think it is, unless someone can put a stake in to say that's wrong.

> > 2.1/2.2: The requirements (2.2) should go first in section 2. The client 
> > types
> > are part of deciding the requirements, and the c

Re: [OAUTH-WG] Draft 20 last call comments

[Justin Richer]

> >> 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
> >> Refresh Token
> 
> >Not sure. What do others think? I put access token first because it is a 
> >more important term to get out of the >way.
> 
> I would rather consider to change order to Access Token, Refresh Token, 
> Authorization Grant since the first two are the core OAuth concepts 
> developers must become familiar with. Authorization grants are "just" an mean 
> to an end to get the token for certain client types. Moreover, I expect the 
> number of authorization grants to increase over time.

You have to use *some* kind of authorization grant to get any kind of
token, and this part of the OAuth spec is all about "how to get a token
in a programmatic way". I agree that there will be many more types of
auth grants in the future, and that's why I think it should be the first
concept in the list.

I can see the logic of putting both token types first (though I still
prefer the auth grant first), but having the auth grant in between the
two token types is definitely a bad idea.

 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SSO scenario

[Justin Richer]

This description actually sounds a lot like the user-agent flow (aka,
"implicit authorization grant") in OAuth2 more than it does a true
two-legged system. The user is still there, and there's still a client
and protected resource, it's just that they're fairly tightly tied.

When using the implicit flow, one of the things you rely on for
verification of the client is the callback url. In this case, it can be
completely pre-registered back to something that the AS/PR has direct
control over.

If you wanted to do a more traditional two-legged approach, you can use
the client-credentials flow between the two servers and have the user's
identity just be asserted as part of an explicit API call. But since you
have a user in the loop, you might as well use them and do a real
three-legged kind of thing.

Additionally, the "user is logged in" bits could be handled by using
OpenID Connect if he wants to go in that direction. At a very high
level, the user ID basically becomes an OAuth2 protected resource, thus
allowing you to log in from any where you can get an access token.
(Connect folks, please feel free to chime in and tell Justin how wrong I
am.)

 -- Justin

On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote:
> I tried to help Justin off-list, but it would be nice to have a FAQ
> somewhere that shows developers how to translate from OAuth 1.1 to OAuth
> 2.0, even just conceptually (as in, "they got rid of the legs, how do I
> do two-legged auth in OAuth 2.0?!?").
> 
> On 8/26/11 5:04 PM, Justin Karneges wrote:
> > Hi folks,
> > 
> > I currently use a proprietary token approach to provide authentication to a 
> > browser widget, and I wonder if OAuth could be used to replace it.
> > 
> > Here's how the system currently works:
> >   - website supports authenticated users (happens via username/password 
> > form)
> >   - website and widget provider have a shared secret
> >   - the website serves a page to the browser, containing an embed of a 
> > remote 
> > widget as well as a token that asserts the currently logged in user.  the 
> > widget takes this token and performs an ajax call to the widget provider 
> > server.  behold, the user is now logged in to the widget.
> > 
> > In trying to organize this into OAuth terms and roles, here is what I come 
> > up 
> > with:
> >   - resource owner: the user
> >   - resource server: widget provider (where the resource is generically 
> > "the 
> > ability to utilize the widget")
> >   - client: the webpage running in the browser
> >   - authorization server: the website
> > 
> > The website essentially serves up the client application and token in one 
> > shot, so the client never has to explicitly ask for a token.  However, the 
> > client would then take that token and use it to access a service.  The 
> > website 
> > and widget provider would share key material such that token validation is 
> > possible, but it's important to note that the two services are not owned 
> > and 
> > operated by the same people.
> > 
> > Does this seem right?  Normally when I think of OAuth, I think of a user 
> > giving a third-party service access to his personal stuff, but in the above 
> > flow 
> > I'm proposing that OAuth be used so that the user gains access to his own 
> > stuff.  In fact, there would be no way to access his stuff other than this 
> > approach, so it's not just about optional third-party access.  It's the 
> > direct 
> > and only access.
> > 
> > Would love confirmation that OAuth is appropriate for my needs, and if I 
> > have 
> > the roles right in that case.
> > 
> > Thanks,
> > Justin
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SSO scenario

[Justin Richer]

You can actually issue a JWT as an access token (since OAuth doesn't 
care about the token format), so in this case the JWT would be used to 
get access to the widget provider. The JWT would be a pre-signed bearer 
token that the provider would know how to check.


 -- Justin

On 9/2/2011 6:50 PM, Justin Karneges wrote:

Very nice.  The token format is straightforward, and not terribly unlike our
current "proprietary" approach (we use CSV instead of JSON, but at the end of
the day it's a bunch of fields and HMAC).  Even if all we did was swap out our
current format for JWT, I think that would be a big win.

So, in the context of OAuth, the website could provide a JWT-formatted
Authorization Grant with the page, and then the client could pass that grant
to the widget provider to obtain an access token.  The token could then be
used to access resources at the widget provider.

JWT grant fields:
   iss = website
   prn = the user logged into the website?
   aud = widget provider

Does this seem right?

One other question: can the access token step be bypassed, such that a
resource can be accessed directly with the grant?

Thanks
Justin

On Wednesday, August 31, 2011 03:48:20 PM Brian Campbell wrote:

JWT is definitely not at odds with OAuth.  I guess you could say JWT
is potentially complementary in a number of ways (they can be used
together but don't need to be).  Though I'm not aware
of any spec work around it, I suspect many will chose to use JWT as a
bearer access token format.  JWTs can also be used as an OAuth grant
type [1] which is based on similar functionality for SAML tokens [2].

[1] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer

On Wed, Aug 31, 2011 at 3:15 PM, Justin Karneges  wrote:

On Wednesday, August 31, 2011 02:05:58 PM George Fletcher wrote:

You could also use a signed JWT returned by the resource owner (web
site) to be presented to the resource server (widget provider) that the
resource server can validate (e.g. verify the signature). The JWT can
contain scopes, expiry time, etc as needed. If the widget provider needs
to access services at the resource owner, the JWT can contain an
appropriate access_token for the user.

Interesting, I was not aware of JSON Web Tokens until now.  Is there a
relationship to OAuth?  Are they at odds or serve different purposes?

Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] problem statement

[Justin Richer]

Mike,

The basic argument here is that if the app wants to do bad things, and
you go through the process of authorizing it, it's going to be able to
do bad things. Not just to your stolen credentials, either, since it's
now got an access token too.

OAuth's trust model does work with installed applications -- however,
there are several caveats. This is one of them, as is the fact that they
can't be shipped with secured secrets (ie, client secrets). And it's
exactly this acquiescence to their limitations that opens the way for
things like the username/password flow in OAuth2. In this flow, the app
just asks for the user's username and password directly and exchanges
them for an access token. There is still a distinction from logging in
directly with the user's credentials to the API endpoint though. First,
the user's credentials don't get tossed out onto the wire with every
request. This lessens the susceptibility to theft in transmission.
Second, the app doesn't *have* to store the credentials. After the first
step goes through and the app gets a token, it can toss them. That way
nobody can steal the credentials out of an on-disk store after the fact.
If it wants to hang on to them, then yeah, you're absolutely right -- it
has your credentials and you're hosed. But nothing in the OAuth protocol
is going to force a misbehaving application to not do that. Just like
nothing in the OAuth protocol is going to stop phishing attempts to look
like the Twitter login screen. 

A solution to not letting an app steal your credentials is to not use
credentials in the first place and to use things like a rotating token
or a client-side certificate instead of a username/password to
authenticate the user during the authoirzation flow. Since OAuth doesn't
care how the user authenticates in the verification code flow, you don't
even have to change your client code. We actually had this happen
locally when developers moved from one environment that used
username/password and into another that used OpenID. The OAuth code
didn't change at all between them.

But ultimately, a bad app is going to be a bad app, and you need to be
careful what software you run and where you type your password. I think
it's a mistake of this group to flippantly ignore the threat, but at the
same token this reality does not make the OAuth protocol or its
underlying model useless.

 -- Justin



On Tue, 2011-09-06 at 14:34 -0400, Michael Thomas wrote:
> Eran Hammer-Lahav wrote:
> > Don't install crap on you device or computer. OAuth is the least of your 
> > concern if you install bad software. 
> > 
> > If there was a solution to this we would not need an antivirus. 
> 
> How exactly does an end user know what is "crap" or not? Or are you just 
> dismissive of apps in
> general? I don't think that apple and google are going to close up shop 
> because it breaks oauth's
> trust model.
> 
> Mike
> 
> > 
> > EHL 
> > 
> > On Sep 6, 2011, at 11:23, "Michael Thomas"  wrote:
> > 
> >> Eran Hammer-Lahav wrote:
> >>> I agree. If you are going to install a native app, you better trust it 
> >>> not to do bad things. Grabbing your password is the least interesting 
> >>> thing such an app can abuse. I don't see any need to change the v2 draft. 
> >> How, exactly, is the user supposed to protect themselves against rogue 
> >> apps?
> >> It sounds like the solution is to tell them to never use oauth in an app 
> >> at all.
> >>
> >> Is oauth only intended to be used on standalone trustable web browsers? I 
> >> don't recall
> >> seeing that anywhere.
> >>
> >> Mike
> >>
> >>> EHL
> >>>
> >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" 
> >>>  wrote:
> >>>
>  Mike,
> 
>  You've got the problem statement right: allowing the user to authorize  
>  resource access to another party without divulging user's credentials is 
>  the objective of OAuth. You are also right in that the attack you have 
>  described defies the whole purpose of OAuth.  I do not think though that 
>  it is related to OAuth per se.
> 
>  To this end, the security work led by Torsten has thoroughly analyzed 
>  the protocol and specified protection against multiple protocol 
>  attacks.  From what you described, it appears to me that the attack you 
>  mention is not related to the protocol but rather to the user's 
>  environment.  There is no possible protection from key loggers that a 
>  protocol can implement. I could be mistaken; in any case, it looks like 
>  the problem rests with the implementation of WebView.
> 
>  If I am wrong, I would appreciate a detailed description of what 
>  happened.
> 
>  Igor
> 
>  On 9/6/2011 1:40 PM, Michael Thomas wrote:
> > Hi all,
> >
> > Barry suggested that I might subscribe and explain what I sent him.
> >
> > My basic problem is that in neither the protocol nor the threats drafts,
> > I can't seem to find what problem is actually trying to 

Re: [OAUTH-WG] problem statement

[Justin Richer]

Mike,

I think this is a red herring. as this vector has nothing to do with
mobile apps. The attack that you've suggested is also possible with a
compromised browser on a desktop using the web flow. In this case, the
browser (UA) can steal the user's credentials and hand them to whoever
they want to when the user gets redirected. It doesn't have to be the
OAuth client that's phishing the credentials, after all. 

OAuth *does* work with phone apps, and it's a misnomer to say that it's
not a good idea in such environments. In all cases, you have to trust
the user agent and all of the mechanisms that let the user log into the
host site. But you have to do that in order to let the user log into the
host site at all. Fixing that is a larger problem for the web as a whole
and ultimately outside of OAuth.

 -- Justin

On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote:
> Melinda Shore wrote:
> > On 09/06/2011 11:11 AM, Jill Burrows wrote:
> >> I repeat, it is not an OAuth problem.
> > 
> > If I'm reading Mike correctly (and if I'm not it won't be the
> > first time I've misunderstood him), he's not really asking for
> > OAUTH to solve this particular problem but to clarify the
> > documents and beef up discussions of what is and is not in
> > scope.  He read the document and couldn't figure out whether
> > or not this particular problem is the business of the working
> > group.
> 
> I'm fairly certain that if somebody were deploying oauth for their servers
> that unless the document told me that oauth doesn't provide protection
> against third party snooping if it's embedded in any app, most people wouldn't
> have a clue that that was a dangerous assumption.
> 
> What this says is that oauth only works in one use case, and that only the
> user can tell the difference. Given the proliferation of phone apps and
> embedded webviews, it seems that the original assumptions of oauth are
> no longer up to date.
> 
> Mike
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] problem statement

[Justin Richer]

Ah, guess that settles it then. Mike, if you have any suggested text to
make this point clearer in the spec, this is probably the best place to
put it.

 -- Justin

On Tue, 2011-09-06 at 23:52 -0400, Manger, James H wrote:
> A strange aspects of this thread is that the current draft already talks 
> about exactly this issue:
> 
> draft-ietf-oauth-v2-21 section 9 "Native Applications"
> 
>   "...Native applications can invoke an external user-agent or
>   embed a user-agent within the application
>   ...
>   Embedded user-agents pose a security challenge because resource
>   owners are authenticating in an unidentified window without access
>   to the visual protections found in most external user-agents.
>   Embedded user-agents educate end-user to trust unidentified
>   requests for authentication (making phishing attacks easier to
>   execute)."
> 
> The webView that Michael Thomas talks about is an "embedded user-agent".
> 
> --
> James Manger
> 
> 
> --
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Michael Thomas
> 
> ...
> At this point, it would be just nice for the industry to know that the issue
> even *exists*.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Nit: Language in section 1.1

[Justin Richer]

+1, this wording is much clearer to me, too

 -- justin

On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote:
> This part of section 1.1 is confusing to me and I stumble whenever I
> read it – I see that Brian Eaton suggested looking at it a while back
> but I don’t think it got changed:
> 
>  
> 
> “OAuth includes four roles working together to grant and provide
> 
>access to protected resources - access restricted resources
> requiring
> 
>authentication:”
> 
>  
> 
> I would suggest something simpler, such as:
> 
>  
> 
> “OAuth includes four roles that work together to grant and provide
> access to protected resources that require authentication.”
> 
>  
> 
>  
> 
> Gregory Brail   |   Technology   |   Apigee   |   +1-650-937-9302
> 
>  
> 
> 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Justin Richer]

I also want to voice support for this. We've implemented an earlier
version of this on a few of our projects as well.

 -- Justin

On Fri, 2011-09-16 at 16:06 -0400, Chuck Mortimore wrote:
> If it's not already implicit by our implementation, I'm voicing our
> support for this becoming a working group item.   
> 
> - cmort
> 
> On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt"
>  wrote:
> 
> 
> 
> > Hi all,
> > 
> > I just published a new revision of the token revocation draft. We
> > added JSONP support (thanks to Marius) and aligned the text with
> > draft 21 of the core spec.
> > 
> > We would like to bring this draft forward as working group item
> > (once the WG is ready). We think its relevance is illustrated by the
> > fact that this draft (or its predecessor) has already been
> > implemented by Google, Salesforce, and Deutsche Telekom.
> > 
> > regards,
> > Torsten.
> > 
> >  Original-Nachricht  
> >  Betreff: 
> > New Version Notification for
> > draft-lodderstedt-oauth-revocation-03.txt
> >Datum: 
> > Fri, 16 Sep 2011 12:20:14 -0700
> >  Von: 
> > internet-dra...@ietf.org
> >   An: 
> > tors...@lodderstedt.net
> >   CC: 
> > sdro...@gmx.de,
> > tors...@lodderstedt.net,
> > mscurte...@google.com
> > 
> > 
> > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been 
> > successfully submitted by Torsten Lodderstedt and posted to the IETF 
> > repository.
> > 
> > Filename:draft-lodderstedt-oauth-revocation
> > Revision:03
> > Title:   Token Revocation
> > Creation date:   2011-09-16
> > WG ID:   Individual Submission
> > Number of pages: 6
> > 
> > Abstract:
> >This draft proposes an additional endpoint for OAuth authorization
> >servers for revoking tokens.
> > 
> > 
> >   
> > 
> > 
> > The IETF Secretariat
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> > 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

+1

I would also prefer to not restrict scope values but provide clear
encoding for places where transport is going to be an issue. This is
what we do with tokens, which show up in the same places. Am I missing
the reason we can't use the exact same rules (modulo the single space
character) that apply to tokens? 

 -- Justin

On Tue, 2011-10-04 at 19:52 -0400, Mark Lentczner wrote:
> 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, I think the URI-escaping is least likely to trip
> developers up. One must be aware, though, that if there is only one
> scope string to provide, and it meets the token production, then the
> scope needn't be in quotes.
> 
> 
> I believe RFC 5987 is vast over-kill in this case. We have no need to
> enable multiple different encodings, nor multiple encodings with a
> single header. Further, I wonder how widespread support for it is in
> various HTTP frameworks.
> 
> 
>   - Mark
> 
> 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of -22

[Justin Richer]

+1

Leave the current text as is, keep this part of OAuth token-type
agnostic. 

 -- Justin

On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote:
> +1
> 
> 
> Phil
> 
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> 
> 
> 
> 
> 
> On 2011-11-02, at 1:06 PM, John Bradley wrote:
> 
> > +1
> > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:
> > 
> > > Hi Stephen,
> > > 
> > > I'm concerned about your proposal (7) to make support for MAC a
> > > MUST for clients and BEARER a MAY only. In my opinion, this does
> > > not reflect the group's consensus. Beside this, the security
> > > threat analysis justifies usage of BEARER for nearly all use cases
> > > as long as HTTPS (incl. server authentication) can be utilized.
> > > regards,
> > > Torsten.
> > > 
> > > Am 13.10.2011 19:13, schrieb Stephen Farrell: 
> > > > 
> > > > Hi all, 
> > > > 
> > > > Sorry for having been quite slow with this, but I had a bunch 
> > > > of travel recently. 
> > > > 
> > > > Anyway, my AD comments on -22 are attached. I think that the 
> > > > first list has the ones that need some change before we push 
> > > > this out for IETF LC, there might or might not be something 
> > > > to change as a result of the 2nd list of questions and the 
> > > > rest are really nits can be handled either now or later. 
> > > > 
> > > > Thanks for all your work on this so far - its nearly there 
> > > > IMO and we should be able to get the IETF LC started once 
> > > > these few things are dealt with. 
> > > > 
> > > > Cheers, 
> > > > S. 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > 
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authentication Methods

[Justin Richer]

Please clarify what you're asking, if you would: There are two kinds of
authentication which happen with OAuth: client authentication and user
authentication, and neither of which are standardized on two-way TLS. 

Client authentication happens at the token endpoint and is described in
section 2.3, which recommends use of HTTP Basic but allows for form
parameters or other, out-of-scope methods such as client assertions. 

User authentication happens at the authorization endpoint and is
completely outside of the scope of OAuth (by design). You can use
whatever means you like to authenticate the user here, from a local
username/password, OpenID, SAML, NTLM, whatever. OAuth makes no
assumptions about how that happens and makes no recommendations, either.

 -- Justin

On Wed, 2011-11-02 at 16:59 -0400, Elliot Cameron wrote:
> What are some common or suggested authentication methods that are used
> in conjunction with OAuth 2.0?
> Is TLS/SSL the only standard one or do people normally roll their own
> authentication within OAuth's flows?
> 
> Elliot Cameron
> 
> Covenant Eyes Software Developer
> 
> elliot.came...@covenanteyes.com
> 
> 810-771-8322
> 
> 
> Call 810-771-8322
> Phone to call with
> Covenant Eyes
> 
>  
>  
> Connect
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of -22

[Justin Richer]

This is exactly what I was thinking of. If a given token type is MTI for
clients, but servers can do whatever they want (this, as I read it, is
what was suggested), how does the MTI bit help interop at all?

 -- Justin

On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote:
> I actually think the protected resource specifies the token type(s) in
> either it's service docs or discovery information, and it does know
> knowing it's authentication server will issue compatible tokens.  The
> client may encounter endpoints requiring token types it doesn't
> support, and it needs to fail gracefully.  The client may select any
> supported OAuth 2 scheme it understands which the PR supports.
> 
> 
> 
> I am not in favor of specifying MUST for any particular flavor of
> token.
> 
> 
> What is the value of mandating a token type?
> 
> 
> 
> -bill
> 
> 
> 
> 
> __
> From: Eran Hammer-Lahav 
> To: John Bradley ; Torsten Lodderstedt
> 
> Cc: "oauth@ietf.org" 
> Sent: Wednesday, November 2, 2011 1:11 PM
> Subject: Re: [OAUTH-WG] AD review of -22
> 
> Do you want to see no change or adjust it to client must implement
> both, server decides which to use.
>  
> EHL
>  
> 
> __
> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of
> John Bradley [ve7...@ve7jtb.com]
> Sent: Wednesday, November 02, 2011 1:06 PM
> To: Torsten Lodderstedt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of -22
> 
> 
> 
> +1
> On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:
> 
> > Hi Stephen,
> > 
> > I'm concerned about your proposal (7) to make support for MAC a MUST
> > for clients and BEARER a MAY only. In my opinion, this does not
> > reflect the group's consensus. Beside this, the security threat
> > analysis justifies usage of BEARER for nearly all use cases as long
> > as HTTPS (incl. server authentication) can be utilized.
> > regards,
> > Torsten.
> > 
> > Am 13.10.2011 19:13, schrieb Stephen Farrell: 
> > > 
> > > Hi all, 
> > > 
> > > Sorry for having been quite slow with this, but I had a bunch 
> > > of travel recently. 
> > > 
> > > Anyway, my AD comments on -22 are attached. I think that the 
> > > first list has the ones that need some change before we push 
> > > this out for IETF LC, there might or might not be something 
> > > to change as a result of the 2nd list of questions and the 
> > > rest are really nits can be handled either now or later. 
> > > 
> > > Thanks for all your work on this so far - its nearly there 
> > > IMO and we should be able to get the IETF LC started once 
> > > these few things are dealt with. 
> > > 
> > > Cheers, 
> > > S. 
> > > 
> > > 
> > > 
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] questions about implicit grant

[Justin Richer]

> The spec says that this grant type is "optimized for public clients
> known to operate a particular redirection URI".
> (a) What does "public" mean here? In what sense could a client be
> public or private, and why is implicit grant more appropriate for the
> public case?

Section 2.1, client types.

> (b) What does "a particular redirection URI" mean? The role of the
> redirect URI and expectations of how it is handled are identical to
> the code type, right?

Since you can't reliably bake a secret into a public client, you can't
rely on it to validate the client. However, if you are using a trusted
and pre-registered redirection URL, then you are very effectively
identifying the client. A bad actor wouldn't use someone else's redirect
URL because they'd never get the callback.

> The potential appeal of this flow to me is the reduction of steps in
> the case where there is only one type of token needed which does not
> need to be refreshed. In section 4.2 of the spec [1], steps A, B, and
> C where exactly what I expected. However:
> (a) I don't understand the use case for D, E, and F, and I couldn't
> find any discussion of this on the web.
> (b) Moreover, I don't understand why D, E, and F would ever be
> necessary, because the access token is already sent directly to the
> client in step C.

Step C is the server sending back the HTTP redirect in response to step
A. Steps D, and E are the user agent following that HTTP redirect. Step
F is extracting the information from the redirected endpoint. While the
access token is sent back in step C, scripts running in the user agent
don't have easy access to it.

 -- Justin


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] questions about implicit grant

[Justin Richer]

On Tue, 2011-11-15 at 12:41 -0500, John Joseph Bachir wrote:
> Thanks Justin - some more questions below... 
> > What does "public" mean here? In what sense could a client
> be
> > public or private, and why is implicit grant more
> appropriate for the
> > public case?
> Section 2.1, client types.

> 
> My understanding of a public client from this section was a client
> which is distributed and not hosted on a server, such as a desktop or
> mobile app. How is it possible for a web-hosted client to be public?

In a JavaScript client, all of the code is distributed to the end user's
machine to execute locally, as opposed to a server-side script which
only shows the browser its output. In order for JS in the browser to
have a secret, the server that hosts the JS would need to spit out the
secret along with the code. This secret would likely be the same for
every instance of the JS client, and it would be readable by the end
user of all of them, which makes it not really a secret and not really
very useful.

> 
> 
> 
> Step C is the server sending back the HTTP redirect in
> response to step
> A. Steps D, and E are the user agent following that HTTP
> redirect. Step
> F is extracting the information from the redirected endpoint.
> While the
> access token is sent back in step C, scripts running in the
> user agent
> don't have easy access to it.
> 
> 
> Ah whoops, I misread C and D. So here's my real question: Why doesn't
> the user agent send the access token to the server in D? Why does the
> web server have to deliver a script which extracts it locally? Is it
> to facilitate a certain style of applications development?

1) The browser generally doesn't send the fragment to the web server

2) That's just standard deployed practice for such JS clients, and it's
currently the easiest way for the JS to get a ping that the transaction
has completed. 


 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mandatory-to-implement token type

[Justin Richer]

> 1. Should we specify some token type as mandatory to implement?  Why
> or why not (*briefly*)?

No, since I do not believe that the force of compliance with this one
point of the spec will be enough to persuade those who don't want to use
whatever the MTI token type ends up being to use it. Let's say that we
were to pick Bearer, but Example.com decides to only support MAC for
their API. Is it correct to say that Example.com is not really doing
OAuth2? I would argue no, since they're doing everything within spec to
issue tokens, and the tokens that they're issuing are well defined and
within spec as well. So then let's say, hypothetically, that in order
comply with the letter of the law, they implement a Bearer token as well
as MAC. But which type do they issue to clients? Clients have no way of
choosing or discovering which what kind of token comes back (yet). If
Bearer is MTI, how do you even use another token type?

Which brings us to MTI in clients, which makes even less sense. Let's
say that I'm writing a client to talk to Example.com, which hands back
MAC tokens. I want to comply with the spec, so I implement Bearer
support in my client, code paths which will never see the light of day. 

Then there's the argument that a generic library is what's really meant
by "client" here, and that those MUST follow the MTI guidelines. I also
find this to be ludicrous, since client libraries will implement
whatever servers support. A good client library will support *both* MAC
and Bearer together, along with whatever magical tokens that haven't
been dreamed up yet that are getting traction.

Ultimately, I think that our declaring something MTI is a position of
hubris that won't affect how people really use this thing.

 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Justin Richer]

Agree with Rob here. Also, from an application and service developer's
perspective, the check for "TLS compliance" is going to go something
like this:

1) Does that url start with "https"?
2) If yes, I'm compliant!
3) If no, make the url start with "https"
4) Done!

Which will put us in exactly the position Rob outlines here. What we
really want is for people to use suitable socket encryption, whatever
that means at the time of deployment.

 -- Justin

On Thu, 2011-11-17 at 06:51 -0500, Rob Richards wrote:
> I'm saying that it's very difficult for someone to implement an AS that 
> implements TLS 1.2. TLS 1.2 is not supported in the a good number of 
> systems people deploy on. For example, the use of Apache and OpenSSL 
> accounts for a good number of web servers out there. The only way to 
> deploy a conforming AS is to use a not yet released version of openssl, 
> 1.0.1, and rebuild or use a different crypto library and rebuild. The 
> barrier for entry to use OAuth 2.0 has just became to high for the 
> majority of people out there. I have already hit a scenario where the 
> security group for a company has balked at OAuth 2.0, prior to the 
> change relaxing TLS 1.2 usage, because the deployed system did not 
> support TLS 1.2 and it's against policy to use non-vendor approved 
> versions of packages. Requiring TLS 1.2 is going to cause the majority 
> to release non-conforming deployments of OAuth 2, just as it was before 
> the previous change.
> 
> Rob
> 
> On 11/17/11 6:18 AM, Barry Leiba wrote:
> >> Please refer to this thread about the problem with requiring anything more
> >> than TLS 1.0
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html
> >>
> >> You will end up with a spec that virtually no one can implement and be in
> >> conformance with. I still have yet to find an implementation out in the 
> >> wild
> >> that supports anything more than TLS 1.0
> > Are you saying that there's some difficulty in *implementing* TLS 1.2
> > ?  If so, please explain what that difficulty is.
> >
> > If you're saying that TLS 1.2 is not widely deployed, and so it's hard
> > to find two implementations that will actually *use* TLS 1.2 to talk
> > to each other, I have no argument with you.  But that's not the point.
> >   If everyone implements only TLS 1.0, we'll never move forward.  And
> > when TLS 1.2 (or something later) does get rolled out, OAuth
> > implementations will be left behind.  If everyone implements 1.2 AND
> > 1.0, then we'll be ready when things move.
> >
> > I'm pretty sure there'll be trouble getting through the IESG with a
> > MUST for something two versions old, and a SHOULD for the current
> > version.
> >
> > Barry
> >
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MAC Cookies

[Justin Richer]

+1 to dropping cookies.

On 11/19/2011 10:33 AM, Eran Hammer-Lahav wrote:


I would like to drop the cookies support defined in the MAC document 
due to lack of interest from the browser vendors. At this point it is 
most likely going to be an unimplemented proposal. If there is 
interest in the future, it can be proposed in a separate document. 
This will allow us to bring this work to a quick conclusion.


Any objections?

EHL



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] delete access tokens?

[Justin Richer]

Specifically, the DELETE method was rejected as tokens aren't 
necessarily directly URL-addressable from the token endpoint. 
Shoehorning that requirement in order to make it feel more RESTful was 
more of a hack than a few folks (myself included) really wanted to make.


 -- Justin

On 11/29/2011 08:08 AM, Lodderstedt, Torsten wrote:


Hi Bart,

I think this would be a truly RESTful approach. The group discussed 
this topic several months ago and consensus was to use another 
endpoint for token revocation (== deletion). Pls. take a look onto 
http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-02.


regards,

Torsten.

*Von:*Bart Wiegmans [mailto:b...@all4students.nl]
*Gesendet:* Dienstag, 29. November 2011 11:32
*An:* oauth WG
*Betreff:* [OAUTH-WG] delete access tokens?

Hello everybody, again.

This is just me pushing a random idea, but what if you specified that 
clients could ask for access token invalidation by making a DELETE 
request to the token endpoint?


Bart Wiegmans



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: Re: Mandatory-to-implement token type

[Justin Richer]

Forwarding my response to the list. (oops)

 -- Justin

 Original Message 
Subject:Re: [OAUTH-WG] Mandatory-to-implement token type
Date:   Fri, 02 Dec 2011 15:07:39 -0500
From:   Justin Richer 
To: Stephen Farrell 



I still don't think that having an MTI token type actually buys us
anything, and what I *really* don't understand from this entire argument
is the weight that's being put behind "Compliance with OAuth2" and what
that means.

With no MTI token type, we can still have interop for people who claim
to be compliant with "OAuth2 + OAuth2 Bearer", or to borrow the example
below, compliant with "OAuth2 + AWESOME". Both of these are compliant
with "OAuth2" because they use OAuth2 to issue their tokens. *Those*
parts of the library should work just fine to interop between each
other. Since you're getting a JSON or fragment-encoded structure back as
the token, you should be able to toss that into some kind of generic
data structure and hand it to the token-handling part of your library,
which is going to need more smarts to know what to do with it.

A robust OAuth2 library, from server or client perspective, will likely
do both Bearer and Mac and let you pick which you want. A good discovery
system will aid that. An extended library will give you AWESOME tokens
as well. *All* of these should be called compliant with OAuth2, in my
opinion, and in this case it would be compliant with "OAuth2 + Bearer +
MAC + AWESOME". A great library indeed!

Making a MTI misses the point of the composability of the system, does
absolutely nothing for real-world interop due to reasons I've already
laid out in previous emails, will cause people to ignore the spec and be
in noncompliance for something they think is dumb, have unused and
untested code just to claim compliance that nobody cares about, and
ultimately makes us look a bit silly for insisting that one solution
will fit all use cases and that we can have any sense of real authority
in this over developers.

I'd like to point out that there's no MTI token-acquisition flow, which
is arguably more important for worldwide interop and just as untenable a
solution given the reality of the internet -- and I can also guarantee
that we will never see agreement over an MTI grant type / token flow due
to the simple fact that some instances will only do client credentials
for 2-legged and some will do code for 3-legged, and the two of those
probably don't want to talk to each other.

In summary, I suggest that "compliance with OAuth2" be defined in terms
of each of the separate composable documents and their combinations, and
that "compliance with OAuth2" not be limited to a particular combination
of any of them.

 -- Justin

On 12/01/2011 09:27 PM, Stephen Farrell wrote:


 Hiya,

 On 12/02/2011 02:14 AM, Michael D Adams wrote:

 On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
wrote:

 On 12/02/2011 01:38 AM, Michael D Adams wrote:

 So an MTI token type + no client preference is equivalent to there
 only existing one token type.


 Maybe.

 However, no MTI token type + no client preference = no interop.

 So I don't get your argument. (When thinking of interop.)


 I think it's me that doesn't understand your argument.


 That can be mutual:-)


 Suppose an authorization server implements OAuth2 and has some
 requirement that the MTI token type doesn't provide (as William Mills
 suggested), so the server implements token type AWESOME in addition to
 token type MTI.

 Whenever a token is requested, the authorization server issues one of
 type AWESOME.  Type MTI is never issued.

 Why bother implementing type MTI if it's never used?


 That, I think, assumes that the requesting party only ever works with
 the AWESOME token-type issuer. Seems a shame to me that whoever wrote
 that code can't work with any other MTI token-type issuer as well, at
 least.


 Additionally, the authorization server could not implement type MTI
 but claim it did.  There's no way for a third party to verify the
 claim since the authorization server never issues a token of type MTI.


 Irrelevant. I could claim to be handsome. Would work equally
 well.


 If tokens of type MTI are never used by this server, how does the MTI
 token type help interop?Is your argument that this server would say
 "No, we do not support OAuth2.  We do, however, support
 OAuth2+AWESOME."?  That semantic argument I understand, but I am
 ignorant as to how/if it fits into the RFC.


 No, my argument is that there are many servers and many clients on
 the Internet and having them all have a way to interop, if they
 choose to do so, is a good thing in itself. Writing an RFC so that
 its a random pick as to whether they do or don't interop is not IMO
 a good thing.

 S.




 ___
 OAuth mail

Re: [OAUTH-WG] Mandatory-to-implement token type

[Justin Richer]

I agree that the core should remain token agnostic. However, I do see 
value in MAC. The ability to have parameter values signed by a client 
key is important for security in depth, even in a world of pervasive 
server-side TLS. I would like to see MAC tokens mature to the point 
where we could use it in all of our current OAuth 1.0 use cases, but 
that's another thread that I haven't been able to give appropriate 
attention to.


I still think that the MTI language (even the cleaner one that Barry 
proposed here) is a red herring and doesn't buy us much in reality.


 -- Justin

On 12/04/2011 01:51 PM, Eran Hammer-Lahav wrote:

This has been going on for far too long.

There is a well-established gap between the two tokens and those who support 
them and we are NEVER going to reach consensus. Instead we have a war of 
attrition were each side is just keeping at it hoping the other side will give 
up. The only compromise we were able to reach in 2 years is to keep the v2 
specification token agnostic. If we are now going to violate that for the 
perceived notion of interoperability, we should at least do it with due process.

Stephen - In previous discussion, my understanding was that you were opposed to 
publishing OAuth 2.0 without MAC because that would make 2.0 a less secure 
option than 1.0. While, as you stated, this thread is not about security but 
about interoperability, the two are at odds here and you can only have one. If 
the specification picked a winner by making only one required, and if that one 
is Bearer, I see no point whatsoever in spending any more of my time on MAC. It 
would be DOA.

The WG is clearly opposed to making MAC required, but that is not the only 
question to ask. The question for the group is also, do you even want MAC? Are 
you planning on using it? And will you use it alongside Bearer or exclusively?

If there is sufficient WG support for MAC, making Bearer required alone 
violates that spirit because it will make MAC another specification no one 
cares about and we don't need more of those. If there is no sufficient support, 
let's just drop it as a WG item and let it resurface later if at all.

As for the "market has decided" argument - I only want to warn those who use it 
that it is a double-edge-sword. The same people who now use that argument are also the 
members of this group responsible for some of the new astronaut architecture features 
proposed in the rechartering discussion. If you intend to make this your winning 
argument, the WG must then apply the same rational to your other proposals.

EHL



-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:44 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type


Whatever. If the entire WG want to get excited by the difference between
MAY do mac and not mentioning it then fine.

Personally, I'd be more interested in getting done rather than nailing that
final nail into any coffin;-)

S

On 12/04/2011 02:21 PM, Mike Jones wrote:

The core spec should be completely silent on MAC, as it is not ready for

prime time.

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:20 AM
To: Paul Madsen
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type


FWIW, if Barry's suggested text was amended to say "MUST do bearer,

MAY do mac" I'd still be ok with that.

Much as I'd like if the mac scheme were more popular, my comment on -22

was interop and not really security related.

S

On 12/04/2011 01:15 PM, Paul Madsen wrote:

Commercial OAuth authorization servers are neither 'toolkits' nor
'purpose built code' - not used to build OAuth clients/servers but
yet required to support more variety in deployments than a single
purpose built server.

But, that variety is driven by customer demand, and none of ours
(yet?) have demanded MAC. If and when that demand comes, we will

add support.

To stipulate MAC as MTI would in no way reflect what the market wants.
And 'interop' nobody wants is not meaningful interop.

paul

On 12/3/11 4:37 PM, Barry Leiba wrote:

Stephen says:

On 12/02/2011 03:20 AM, Barry Leiba wrote:

Maybe what would work best is some text that suggests what I say
above: that toolkits intended for use in implementing OAuth
services in general... implement [X and/or Y], and that code
written for a specific environment implement what makes sense for

that environment.

It seems to me that to require any particular implementation in
the latter case is arbitrary and counter-productive, and doesn't
help anything interoperate. Whereas general-purpose toolkits that
implement everything DO help interop.

That'd work just fine for me.

OK, so here's what I suggest... I propose adding a new section 7.2, thus:

---
7.2 Access Token Implem

Re: [OAUTH-WG] Mandatory to Implement & Interoperability

[Justin Richer]

+1

Very well said, Hannes.

 -- Justin

On 12/08/2011 09:18 AM, Hannes Tschofenig wrote:

Hi all,

I read through this rather long mail thread again and see whether we are 
reaching any conclusion on this discussion.
In turns out that there are actually two types of discussions that relate to 
each other, namely the TLS version support and the token type.

Let me go back in time a little bit when I was still chairing another working 
group (years ago), namely the KEYPROV working group. There we ran into a 
similar issue, which looked fairly simple at the beginning. We worked on 
Portable Symmetric Key Container (PSKC),  later published as RFC 6030. We were 
at the stage where we thought we had to decide on a mandatory-to-implement 
cryptographic algorithm and, similar to the OAuth case, PSKC is one building 
block in a larger protocol suite. As you can imagine, everyone had their own 
deployment environment in mind and did not like the suggestion others made 
about what as mandatory to implement.

Russ (now IETF chair and at that time security area director) told the group 
not to worry - we don't need to pick an algorithm. He suggested to just provide 
a recommendation of what is best in a specific deployment environment (at the 
time of writing). In fact, he proposed to publish a separate document instead 
to discussing it in that document.

I was surprised because I was couldn't see how one would accomplish 
interoperability. Russ told me that this is in practice not a problem because 
implementations often implement a range of cryptographic algorithms anyway. 
Then, as part of the algorithm negotiation procedure (or some discovery) they 
will figure out what both end points support. He further argued that algorithm 
preferences will change (as algorithms get old) and we don't want to update our 
specifications all the time. (This was a bit motivated by the MD5 clean-up that 
happened at that time.) [Please forgive me if I do not recall the exact words 
he said many years ago.]

I believe we are having a similar discussion here as well, both with the token 
type but also with the TLS version. We look at individual specifications 
because we are used to add security consideration sections to each and every 
document. Unfortunately, the most useful statements about security (for these 
multi-party protocols where the functionality is spread over multiple 
documents) can really only be made at a higher level. Our approach for 
describing security threats and for recommending countermeasures isn't suitable 
to all the documents we produce.

Let me list a few desirable results of our standardization work:

1) Everyone wants interoperability. We can do interop testing of building 
blocks to see whether a client and a server are able to interact. For example, 
we could write a few test cases to see how two independent bearer token 
specifications work with each other. That approach works for some of our 
building blocks. I do, however, believe that we are more interested of an 
interoperable system consisting of several components rather than having 
interop between random components. Even if we do not like it, OAuth is an 
application level protocol that requires a number of things to be in place to 
make sense.

2) We want libraries to be available that allow implementers to quickly 
"OAuth-enable" their Web applications, i.e., by quickly I mean that an 
application develop shouldn't have to write everything from scratch. Most of the 
development time will be spent on aspects that are not subject to standardization in the 
working group (such as the user interface and the actual application semantic -- the data 
sharing that happens once the authorization step is completed). These libraries are 
likely to support various extensions and getting two different implementations to 
interwork will IMHO in practice not be a problem. However, for a real deployment it seems 
that the current direction where people are going is more in the line of trust frameworks 
where much more than just technical interoperability is needed for a working system. See 
the discussions around NSTIC for that matter.

3) We want the ability for algorithm negotiation/discovery, at least up to a 
certain degree. For example, it would would nice if a client talks to a server 
and they both implement TLS 1.2 then they actually use it. The requirement for 
crypto-agility fits in here as well.

4) We want to separate the protocol specification from the cryptographic 
algorithms and other faster changing components. We don't want to update our 
protocol specification just because an algorithm becomes obsolete or the 
protocol suddenly gets used in a different environment where other constraints 
may be prevalent.

5) The security analysis and the solution approaches will vary based on the 
deployment environment. During the Taipei OAuth WG meeting I tried to explain 
what I mean with this statement with my reference to NIST SP 800-63. For so

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Justin Richer]

Agreed -- I think that this text addresses the concerns of those who had 
them without getting in too deep to things that are, quite frankly, 
ancillary to OAuth. I still contend that the vast majority of 
implementors reading this will see that line and say "Oh, I need an 
https there instead of an http" and call it a day, but the proposed text 
doesn't *hurt* that case, so I'm relatively fine with it.


 -- Justin

On 12/11/2011 12:28 PM, William Mills wrote:

I think it's overkill, but I don't think it causes any problems.


*From:* Rob Richards 
*To:* Mike Jones 
*Cc:* Barry Leiba ; oauth WG 
*Sent:* Saturday, December 10, 2011 11:26 AM
*Subject:* Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

I am fine with it

Rob

On 12/9/11 1:30 PM, Mike Jones wrote:
> It looks to me like there is consensus for Barry's text (below).  
Agreed?

>
> -- Mike
>
> NEW
> 
> The authorization server MUST implement TLS.  Which version(s) ought 
to be implemented will vary over time, and depend on the widespread 
deployment and known security vulnerabilities at the time of 
implementation.  At the time of this writing, TLS version 1.2 
[RFC5246] is the most recent version, but has very limited actual 
deployment, and might not be readily available in implementation 
toolkits.  TLS version 1.0 [RFC2246] is the most widely deployed 
version, and will give the broadest interoperability.

>
> Servers MAY also implement additional transport-layer mechanisms 
that meet their security requirements.

> 
>
> -Original Message-
> From: oauth-boun...@ietf.org  
[mailto:oauth-boun...@ietf.org ] On 
Behalf Of Peter Saint-Andre

> Sent: Thursday, December 01, 2011 12:59 PM
> To: Stephen Farrell
> Cc: Barry Leiba; oauth WG
> Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
>
> On 12/1/11 1:57 PM, Stephen Farrell wrote:
>>
>> On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
>>> On 12/1/11 1:09 PM, Rob Richards wrote:
 On 11/28/11 10:39 PM, Barry Leiba wrote:
>> The OAuth base doc refers in two places to TLS versions (with the
>> same text in both places:
>>
>> OLD
>> The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
>> support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
>> support additional transport-layer mechanisms meeting its security
>> requirements.
>>
>> In both the shepherd review and the AD review, this was called
>> into
>> question:
>> 1. MUST for an old version and SHOULD for the current version
>> seems wrong.
>> 2. Having specific versions required locks us into those versions
>> (for example, all implementations will have to support TLS 1.0,
>> even long after it becomes obsolete, unless we rev the spec.
> The comments I've gotten on this show a clear consensus against the
> change I suggest, and against any attempt to require a version of
> TLS other than 1.0.  I still, though, am concerned that locking
> this spec into TLS 1.0 is limiting.  So let me propose an
> alternative wording, which again tries to make the version(s)
> non-normative, while making it clear which version(s) need to be
> implemented to get
> interoperability:
>
> NEW
> 
> The authorization server MUST implement TLS.  Which version(s)
> ought to be implemented will vary over time, and depend on the
> widespread deployment and known security vulnerabilities at the
> time of implementation.  At the time of this writing, TLS version
> 1.2 [RFC5246] is the most recent version, but has very limited
> actual deployment, and might not be readily available in
> implementation toolkits.  TLS version 1.0 [RFC2246] is the most
> widely deployed version, and will give the broadest
> interoperability.
>
> Servers MAY also implement additional transport-layer mechanisms
> that meet their security requirements.
> 
>
> Comments on this version?
>
> Barry
>
 Text is neutral enough for me as it's not mandating anything that
 isn't readily available. Only comment is whether or not there is a
 need to even talk about the specific versions or if just the
 following is
 enough:

 The authorization server MUST implement TLS. Which version(s) ought
 to be implemented will vary over time, and depend on the widespread
 deployment and known security vulnerabilities at the time of
 implementation.

 Servers MAY also implement additional transport-layer mechanisms
 that meet their security requirements.
>>> That seems fine to me.
>> FWIW, I think I'd prefer Bar

Re: [OAUTH-WG] conflict: error response invalid_request and state parameter duplication

[Justin Richer]

The spec already says that you can't repeat request parameters on the 
line like that, so that's an invalid_request error, as described in 
section 5.2:



 5.2. Error Response



   The authorization server responds with an HTTP 400 (Bad Request)
   status code and includes the following parameters with the response:

   error
 REQUIRED.  A single error code from the following:
 invalid_request
   The request is missing a required parameter, includes an
   unsupported parameter value, repeats a parameter,
   includes multiple credentials, utilizes more than one
   mechanism for authenticating the client, or is otherwise
   malformed.



 -- Justin

On 12/19/2011 08:20 AM, Alexey Skolyarov wrote:


Hello Buhake,

Thanks for your answer!

It seems I should explain a bit here -- I'm not about how to pass the 
state with multiple values, I'm trying to figure out how the 
OAuth-2.0-draft-22 -- compliant server should respond on duplication 
of state request parameter.


For instance what should be returned in response on following request:

GET 
/authorize?response_type=code&client_id=s6BhdRkqt3&*state=QWE*&*state=ASD*&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 
HTTP/1.1


Host: server.example.com

It's unclear for me should it be

HTTP/1.1 302 Found

Location: https://client.example.com/cb?error=invalid_request (without 
the state completely -- seems to be wrong beforehand)


or

HTTP/1.1 302 Found

Location: 
https://client.example.com/cb?error=invalid_request&state=QWE( or ASD 
- one of passed states used)


or

HTTP/1.1 302 Found

Location: 
https://client.example.com/cb?error=invalid_request&state=QWE%20ASD 
(both but violates the idea that state should be kept unchanged).


I hope this example could make my question clearer.

Thanks in advance.

--
Best regards, Alexey Skolyarov

*From:*Buhake Sindi [mailto:buh...@googlemail.com]
*Sent:* Monday, December 19, 2011 4:53 PM
*To:* Alexey Skolyarov
*Subject:* Re: [OAUTH-WG] conflict: error response invalid_request and 
state parameter duplication


Hi Alexey,

If I'm not mistaken, to declare multiple values in "state", the 
document states that it should be space-delimited (" "). This is 
unlike Facebook state which is comma-delimited.


On 19 December 2011 14:41, Alexey Skolyarov > wrote:


Hello everybody,

Since this is my first post on this list, I'll say few words about whoami:

My name is Alexey Skolyarov, I work in Saint-Petersburg, Russia. I'm 
interested in OAuth2 because I found no v2 providers for Jersey 
 except Spring Security which is much more 
complex than 1.0a implementation in Jersey-contrib. Currently I'm 
under NDA, so I can't say more L


Nevertheless we've done specification study and found a conflict -- in 
last paragraph of section 3.1. "Authorization Endpoint" 
 it is 
mentioned that "/Request and response parameters MUST NOT be included 
more than once/".


This statement conflicts with /state/ parameter definition in section 
4.1.2.1 "Error response" 
, 
where it's said that state is "/REQUIRED if a valid "state" parameter 
was present in the client  authorization request.  The exact value 
received from the client/".


How passing /state=QWE&state=ASD/ inside same request should be 
handled then?


From one hand it is forbidden to process requests with multiple 
parameter occurrences.


But from another hand Specification requires to pass the state if it 
was found in a request.


Violation of any of these statements can be treated as "partial 
compliance" to draft-22, so I'm in doubt what way is preferred there.


What do you guys think?

Thanks in advance.

--
Best regards, Alexey Skolyarov


___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




--
The Elite Gentleman



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Native clients & 'confidentiality'

[Justin Richer]

Native mobile clients can't really be confidential clients.

The distinction between "public" and "confidential" clients is whether 
or not they can keep deployment-time secrets; which is to say, a 
client_secret. This is not to say that they can't keep *any* secrets. In 
particular those generated at runtime, like an access token or refresh 
token, could be held perfectly safe. But at the time the app is deployed 
to its running environment, you have to ask "who has access to its code 
and configuration?"


Think of it this way. In the standard world, a native app gets copied to 
every device with the client_id and client_secret baked in. This makes 
the client_secret not very secret, and not at all unique. Anybody with 
access to the binary -- which is to say, every user -- could decompile 
the client_secret out of it and bake it into their *own* client, 
pretending to be your app and causing all kinds of havoc. This is a very 
different problem from somebody breaking into the token store and 
stealing an access token, which lets them only get to their own account.


Compare this to a server-based app where the only ones with access to 
the binary and configuration are the administrators of the server, not 
the end users. It's a much more limited list of folks that can 
potentially see it, and therefore the client_secret can actually mean 
something and add a small extra layer of security.


There are a few ways to mitigate this difference for public clients, 
such as using some kind of dynamic registration for all clients (which 
doesn't buy you much in terms of overall security) or putting up scary 
messages about native clients to try and educate your users. You can 
also use a trusted callback URL for your app on a hosted website that 
works in conjunction with your native app. This is actually the 
suggested use for the Implicit Flow, which was made for public clients 
in the browser.


Native apps also have the concern of embedded browsers vs. external 
native browsers, and what trust the user puts into them. For all OAuth 
flows, you have to trust the browser provider on the platform of choice, 
since the user's going to be logging in directly through that browser. 
It's very much outside the scope of OAuth to make that world any better 
though, and there have been long and detailed discussions on this list 
about that very topic, leading to some concrete recommendations in the 
draft as it stands today.


To answer your original query: I don't think that mandating one kind of 
client vs. the other will really help. OAuth 1.0 only had "confidential" 
clients, and that led to inane workarounds like Google's 
"anonymous/anonymous" client id/secret.


Hope this helps.

 -- Justin

On 12/19/2011 07:19 AM, Paul Madsen wrote:
Hi, the Online Media Authorization Protocol (OMAP) is a (as yet 
unreleased) profile of OAuth 2.0 for online delivery of video content 
based on a user's subscriptions (the TV Everywhere use case)


We want to support both server & native mobile clients. It is for the 
second class of clients that I'd appreciate some clarification of 
'confidentiality' as defined in OAuth 2.


OAuth 2 distinguishes confidential & public clients based on their 
ability to secure the credentials they'd use to authenticate to an AS 
- confidential clients can protect those credentials, public clients 
can't.


Notwithstanding the above definition, the spec gives a degree of 
discretion to the AS


The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure
levels of client credentials.


Give this discretion, is itpractical for the OMAP spec to stipulate 
that 'All Clients (both server & native mobile), MUST be 
confidential', ie let each individual OMAP AS specify its own 
requirements of clients and their ability to securely authenticate?


Is this consistent with the OAuth definition of confidentiality?

Thanks

Paul











___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Native clients & 'confidentiality'

[Justin Richer]

A part of what George has outlined below is captured in the OpenID 
Connect Dynamic Registration flow. In that, the Dynamic Registration 
endpoint MAY be an OAuth2 protected resource. If you could mint your 
distributed clients with unique identifiers of some type, they could use 
those as bearer tokens to the registration endpoint, thereby getting a 
client id and secret.


The AS still has to keep track of all of these registered clients, and 
you've still got to find some way mint and manage all of those bearer 
tokens in the first place. But this approach does at least give you an 
OAuth-friendly way to bootstrap the whole process.


 -- Justin

On 12/19/2011 02:10 PM, George Fletcher wrote:

Hi Paul,

Is the need to authenticate the client a need to ensure that the 
content is only displayed on certain devices/clients? Or prevent 
phishing/stealing of authz bearer tokens?


As you point out, it's possible to protect the bearer tokens and 
associated refresh tokens "via other mitigating mechanisms". I'm not 
sure it's possible to authenticate the device/client with out the 
device/client having some special "hardware" that can be leveraged in 
the authentication step.


Even dynamic registration doesn't solve the security issues (the 
device/client can still be disassembled and associated values 
discovered) of the device/client, just mitigates the exposure risk. 
However, this does cause increased work for the AS as it will now be 
tracking each and every device as a unique client. It's also likely 
for the device registration steps to be discovered, in which case 
restricting to a particular device again fails.


It seems like trying to bind the bearer token to a device/client 
instance might be a better approach. That way you know that the 
customer correctly authorized that device/client instance and it is 
"allowed" to present the bearer token. Of course enforcing/proving the 
"allowed" part sort of breaks the "bearer" part:)


Thanks,
George

On 12/19/11 1:09 PM, Paul Madsen wrote:

Thanks Justin, FWIW, I agree with your analysis

Seems to me we have the following breakdown of clients

- confidential server clients

- confidential native clients (somewhat theoretical at the moment, 
assumes either 1) a client registration mechanism to deliver 
credentials post installation, such as OpenID Connects Client 
Registration spec, or 2) a distribution channel in which uniquely 
credentials can be packaged into the binary before delivery)


- public clients (no option of client authn, but still possible to 
have some protection against token leakage via other mitigating 
mechanisms)


thanks again

paul

On 12/19/11 12:44 PM, Justin Richer wrote:

Native mobile clients can't really be confidential clients.

The distinction between "public" and "confidential" clients is 
whether or not they can keep deployment-time secrets; which is to 
say, a client_secret. This is not to say that they can't keep *any* 
secrets. In particular those generated at runtime, like an access 
token or refresh token, could be held perfectly safe. But at the 
time the app is deployed to its running environment, you have to ask 
"who has access to its code and configuration?"


Think of it this way. In the standard world, a native app gets 
copied to every device with the client_id and client_secret baked 
in. This makes the client_secret not very secret, and not at all 
unique. Anybody with access to the binary -- which is to say, every 
user -- could decompile the client_secret out of it and bake it into 
their *own* client, pretending to be your app and causing all kinds 
of havoc. This is a very different problem from somebody breaking 
into the token store and stealing an access token, which lets them 
only get to their own account.


Compare this to a server-based app where the only ones with access 
to the binary and configuration are the administrators of the 
server, not the end users. It's a much more limited list of folks 
that can potentially see it, and therefore the client_secret can 
actually mean something and add a small extra layer of security.


There are a few ways to mitigate this difference for public clients, 
such as using some kind of dynamic registration for all clients 
(which doesn't buy you much in terms of overall security) or putting 
up scary messages about native clients to try and educate your 
users. You can also use a trusted callback URL for your app on a 
hosted website that works in conjunction with your native app. This 
is actually the suggested use for the Implicit Flow, which was made 
for public clients in the browser.


Native apps also have the concern of embedded browsers vs. external 
native browsers, and what trust the user puts into them. For all 
OAuth flows, you have to trust the browser provider on the platform 
of choice, since the user's goin

Re: [OAUTH-WG] conflict: error response invalid_request and state parameter duplication

[Justin Richer]

None, it responds with an error (400) and not a redirect (302). You 
don't include the state parameter on an error response, only on a valid 
redirection response.


 -- Justin

On 12/20/2011 01:57 AM, Alexey Skolyarov wrote:


I see that. But how the server should respond on incorrect request 
(when it’s not possible to determine correct state to be passed).


Specifically, what state should be passed to the client – no one, any 
or all of them?


--
Best regards, Alexey Skolyarov
Dino Systems Java Team
Phone: +7 (812) 740-77-61 ext. 4161Skype: alexey.skolyarov

Cell: +7 (905) 200-29-80 Mailto: alexey.skolya...@dins.ru 
<mailto:alexey.skolya...@dins.ru>


*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Monday, December 19, 2011 7:01 PM
*To:* Alexey Skolyarov
*Cc:* Buhake Sindi; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] conflict: error response invalid_request and 
state parameter duplication


The spec already says that you can't repeat request parameters on the 
line like that, so that's an invalid_request error, as described in 
section 5.2:



  5.2.  Error Response

  
  
The authorization server responds with an HTTP 400 (Bad Request)

status code and includes the following parameters with the response:
  
error

  REQUIRED.  A single error code from the following:
  invalid_request
The request is missing a required parameter, includes an
unsupported parameter value, repeats a parameter,
includes multiple credentials, utilizes more than one
mechanism for authenticating the client, or is otherwise
malformed.



 -- Justin

On 12/19/2011 08:20 AM, Alexey Skolyarov wrote:

Hello Buhake,

Thanks for your answer!

It seems I should explain a bit here – I’m not about how to pass the 
state with multiple values, I’m trying to figure out how the 
OAuth-2.0-draft-22 – compliant server should respond on duplication of 
state request parameter.


For instance what should be returned in response on following request:

GET 
/authorize?response_type=code&client_id=s6BhdRkqt3&*state=QWE*&*state=ASD*&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 
HTTP/1.1


Host: server.example.com

It’s unclear for me should it be

HTTP/1.1 302 Found

Location: https://client.example.com/cb?error=invalid_request (without 
the state completely – seems to be wrong beforehand)


or

HTTP/1.1 302 Found

Location: 
https://client.example.com/cb?error=invalid_request&state=QWE 
<https://client.example.com/cb?error=invalid_request&state=QWE>( or 
ASD - one of passed states used)


or

HTTP/1.1 302 Found

Location: 
https://client.example.com/cb?error=invalid_request&state=QWE%20ASD 
<https://client.example.com/cb?error=invalid_request&state=QWE%20ASD> 
(both but violates the idea that state should be kept unchanged).


I hope this example could make my question clearer.

Thanks in advance.

--
Best regards, Alexey Skolyarov


*From:*Buhake Sindi [mailto:buh...@googlemail.com]
*Sent:* Monday, December 19, 2011 4:53 PM
*To:* Alexey Skolyarov
*Subject:* Re: [OAUTH-WG] conflict: error response invalid_request and 
state parameter duplication


Hi Alexey,

If I'm not mistaken, to declare multiple values in "state", the 
document states that it should be space-delimited (" "). This is 
unlike Facebook state which is comma-delimited.


On 19 December 2011 14:41, Alexey Skolyarov <mailto:alexey.skolya...@dins.ru>> wrote:


Hello everybody,

Since this is my first post on this list, I’ll say few words about whoami:

My name is Alexey Skolyarov, I work in Saint-Petersburg, Russia. I’m 
interested in OAuth2 because I found no v2 providers for Jersey 
<http://jersey.java.net/> except Spring Security which is much more 
complex than 1.0a implementation in Jersey-contrib. Currently I’m 
under NDA, so I can’t say more L


Nevertheless we’ve done specification study and found a conflict – in 
last paragraph of section 3.1. "Authorization Endpoint" 
<http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.1> it is 
mentioned that “/Request and response parameters MUST NOT be included 
more than once/”.


This statement conflicts with /state/ parameter definition in section 
4.1.2.1 "Error response" 
<http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.2.1>, 
where it’s said that state is “/REQUIRED if a valid "state" parameter 
was present in the client  authorization request.  The exact value 
received from the client/”.


How passing /state=QWE&state=ASD/ inside same request should be 
handled then?


From one hand it is forbidden to process requests with multiple 
parameter occurrences.


But from another hand Specification requires to pass the state if it 
was found in a request.


Violation of any of these statements can be treated as “partial 

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Justin Richer]

I'm OK with the threat document including a line this this, or Eran's 
proposed text, in the introduction to what OAuth can and can't do. It's 
important to set scope appropriately. (and I am very sorry for that pun)


However, the contention about native apps that Mike brings up is 
misleading for one key reason: if the user's browser is compromised 
(which is the attack vector in question), then all OAuth-backed webapps 
will *also* be compromised, since the bad party can just grab the data 
on its way to the screen. And if the user downloads malware masquerading 
as a good app (which OAuth *can* protect against by using client secrets 
in some circumstances and trusted callback urls in others), and they 
approve the bad app, then they're hosed too.


So, no, OAuth won't protect you against malware-infested browsers or 
against phishing. It significantly reduces but does not eliminate 
security threats, and (a point that hasn't been brought up) it 
significantly eases the cleanup burden on users and service providers in 
the case of a breach. If this really is a confusing point to people, we 
can say that in the threat document, and Bill's text would do that, 
without the addendum about native clients. I believe that the native 
client text that speaks about embedded vs. external browsers is already 
clear on this matter -- but if someone has better text (as in, 
"paragraph X should say the following exact words", not "it needs to be 
better"), then we can incorporate it.


Even so, I do think it's clear from what text we already have. It would 
be superfluous but not burdensome to add extra text into the threat 
model document (not core) as has been proposed here by Bill and 
previously be Eran.


 -- Justin

On 01/04/2012 06:58 PM, Michael Thomas wrote:

On 01/04/2012 03:42 PM, William Mills wrote:
I think the threat draft should simply say, "OAuth does not and can 
not protect the user against credential compromise as a result of 
phishing, malware, social engineering, or machine compromise."


I could live with something like this, but I think it needs to be much 
more
explicit that it applies to any authentication service that allows 
native apps as clients
with no form of strong app vetting. It may even be useful to point to 
a couple of

large deployments who are at risk from this, like, oh say, twitterbook.

If this draft doesn't take a strong stand against that practice, it's 
doing nothing
more than giving a wink and a nod that what twitterbook is currently 
doing is safe.

That's bad, but I suspect it's the elephant in the room.

Mike



Get rid of the fancy rhetoric, we don't need to explain a lot more 
than this.


I don't agree that OAuth purports to solve these problems. What it 
solves is limiting the credentials granted to allow the user more 
control and limited damage in the event of credential misuse.


-bill

---
- 



--

*From:* Michael Thomas 
*To:* Barry Leiba 
*Cc:* oauth WG 
*Sent:* Wednesday, January 4, 2012 1:06 PM
*Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, 
ends 9 Dec 2011


On 01/04/2012 12:41 PM, Barry Leiba wrote:
> up being a compromised browser or a native application that the user
> perhaps unwisely installed, all the security in the framework goes out
^
> the window, because an untrustworthy UA can fiddle with pretty much
> everything.
>

I think the "perhaps unwisely" goes to the heart of my objection. You
might as well be talking about "perhaps unwisely" driving a car,
or "perhaps unwisely" eating food: the reality is that people download
apps by the *billions*.  When I was initially blown off, many of the
participants including document editors implied that only idiots get
apps for their phones. That is *completely* unhelpful as the reality
is that OAUTH's use is hugely if not primarily deployed in that sort of
environment.

This is a threat that cuts to the very heart of what OAUTH is, and 
purports

to defend against: keeping user credentials out of the hands 

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[Justin Richer]

The important thing to realize here is that just having the client_id 
doesn't get you access tokens, and it certainly doesn't give you access 
to all access tokens issued to that client_id in the past. It does allow 
for a phishing scenario in that it will let you try to impersonate a 
known-good client by copying the client_id, but each individual user 
will still have to authorize the fake client in order for it to get a 
new access token.


But keep in mind that this doesn't expose the user's actual credentials 
to the application (on mobile especially, assuming use of external 
browsers trusted by the platform -- as has been discussed on the list 
here, a bad application could always embed a browser and try to steal 
your credentials directly, but they can do that anyway without OAuth). 
The mitigation and cleanup of fake clients like this is also simpler, 
since you can revoke tokens without much cost to users and service 
providers.


These reasons are why it's suggested to use the authorization code flow 
with mobile apps, just without a client_secret. You can lessen the 
attack vector by using a trusted and preregistered callback_uri, and 
there's even been some discussion about how to do that with cloud 
services handling the callbacks for trusted applications on the platform.


 -- Justin

On 01/06/2012 12:34 PM, William Mills wrote:
Yeah, certainly for Mobile clients this is true.  There are classes of 
clients (server to server implementations notably) where clientID can 
be a proper secret and be usefule for client validation.



*From:* Torsten Lodderstedt 
*To:* Karim ; oauth@ietf.org
*Sent:* Friday, January 6, 2012 5:21 AM
*Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id

Hi,

your observation is correct. OAuth security considerations recommend 
not to rely on secrets for authenticating mobile apps (aka native 
apps) but to manage them as so-called public clients. Please take a 
look onto section 10 of the core spec for further details.


regards,
Torsten.



Karim  schrieb:

Hello,

When using User-agent flow with OAuth2 for mobile platform, there
is no way for Authorization server to authenticate the client_id
of the application.

So, anyone can impersonate my app by copying the client_id (and so
get all access tokens on my behalf), and this is applicable to
Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on
the server side, and the client is authenticated using secret key.

-- 
Karim



___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested

[Justin Richer]

What you're describing is the Device Flow, which was pulled out of the 
main document a while ago and now sits here, somewhat outdated and unloved:


http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

In this, the app gives the user a short code that they enter into a URL, 
do the authorization there, and get a short code back. It's effectively 
the same as the auth code flow, but it does the dance without HTTP 
redirects.


 -- Justin

On 01/10/2012 02:23 PM, Gregory Prisament wrote:

Hello,
I am developing a REST API and trying to follow the OAuth 2.0 protocol
for authentication, and have a few questions for you good folks.

The use case I'm interested in is native applications (such as linux
command-line programs) that are unable or unwilling to involve a
user-agent.  In this case, it seems redirection-based flows
("Authorization Code" and "Implicit Grant Types") are out!  That
leaves "Client Credentials" and "Resource Owner Credentials".

"Client Credentials" do not seem appropriate because the client may be
installed on multiple machines and used by different resource owners.

"Resource Owner Credentials" COULD work, but I'd rather not require
the resource owner to reveal their username and password.

One solution, which seems reasonable to me, would be to extend OAuth2
to include another grant type called "Manual Authorization Code".
Using a web browser, the resource owner would login&  authenticate
with the authorization server (using session log-on, etc).  From there
they could enter an Application ID and press a button "Generate Manual
Authorization Code".  The resource owner would then type this Manual
Authorization Code into the client, and the client could exchange it
for an Access Token.

But before I go down this route -- writing an extension, etc.. -- I
wanted the WG's feedback.  It seems there are a few different ways to
handle this use case and was curious which you think best matches the
intentions of the OAuth2 spec.

POSSIBLE APPROACHES:
(1) "Manual Authorization Code" extension.
See description above.

(2) "Client Credentials" with each resource owner registering a separate client.
We could achieve a similar effect to (1) by using "Client
Credentials".  Say the client is a command-line program
"example-client-cli", which a large number of resource owners have
downloaded and installed.  Each resource owner would register the
client with the authorization server and configure their local install
by telling it the client_id and client_secret.

(3) Something else entirely?

QUESTIONS FOR YOUR:
(Q1) Has the WG thought about this particular use case ("CLI clients")
and do you have a recommended authorization approach.
(Q2) Do Manual Authorization Codes make sense?  Would anyone else find
it useful to have - if I were to write up an extension document for
it?


Thanks in advanced for you help!
Cheers,
Greg Prisament
Software Architect
PowerCloud Systems
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested

[Justin Richer]

You definitely can do that with an app-specific password using the 
resource owner password flow, but if you're already doing OAuth, why 
would you want to?


The Device flow fell by the wayside not because people didn't see value 
in it -- many do -- but nobody in the group was actively implementing 
against it and nobody wanted to pick up editorship of it. David did us 
the courtesy of at least capturing those parts of the protocol into a 
document so that they wouldn't be lost entirely, but what it really 
needs now is an editor to step up and see it through to completion. This 
WG is planning to recharter or re-form or something in the near future, 
and if there's a champion behind the Device doc (and someone willing to 
do the actual work of editing the text), then we'll see it come up again.


 -- Justin

On 01/11/2012 01:49 PM, Gregory Prisament wrote:

Correction: Last paragraph should read:
... Do you think an authorization server could implement
application-specific passwords, passing it off as the "resource owner
credentials" grant type...

On Wed, Jan 11, 2012 at 10:47 AM, Gregory Prisament
  wrote:

Thanks for the link, that's very similar to what I'm going for.

Any idea why people lost interest in the Device Flow?  It seems like a
useful option to have!

Also, in doing some research, I came across Google's
"application-specific passwords", which seem to be another way to
solve this problem.
http://support.google.com/mail/bin/answer.py?hl=en&answer=1173270

Any thoughts on application-specific passwords.  Do you think an
authorization server could implement application-specific passwords,
passing it off as the "client credentials" grant type.  Would that be
in spec?

Cheers,
Greg

On Tue, Jan 10, 2012 at 11:47 AM, Justin Richer  wrote:

What you're describing is the Device Flow, which was pulled out of the main
document a while ago and now sits here, somewhat outdated and unloved:

http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

In this, the app gives the user a short code that they enter into a URL, do
the authorization there, and get a short code back. It's effectively the
same as the auth code flow, but it does the dance without HTTP redirects.

  -- Justin


On 01/10/2012 02:23 PM, Gregory Prisament wrote:

Hello,
I am developing a REST API and trying to follow the OAuth 2.0 protocol
for authentication, and have a few questions for you good folks.

The use case I'm interested in is native applications (such as linux
command-line programs) that are unable or unwilling to involve a
user-agent.  In this case, it seems redirection-based flows
("Authorization Code" and "Implicit Grant Types") are out!  That
leaves "Client Credentials" and "Resource Owner Credentials".

"Client Credentials" do not seem appropriate because the client may be
installed on multiple machines and used by different resource owners.

"Resource Owner Credentials" COULD work, but I'd rather not require
the resource owner to reveal their username and password.

One solution, which seems reasonable to me, would be to extend OAuth2
to include another grant type called "Manual Authorization Code".
Using a web browser, the resource owner would login&authenticate

with the authorization server (using session log-on, etc).  From there
they could enter an Application ID and press a button "Generate Manual
Authorization Code".  The resource owner would then type this Manual
Authorization Code into the client, and the client could exchange it
for an Access Token.

But before I go down this route -- writing an extension, etc.. -- I
wanted the WG's feedback.  It seems there are a few different ways to
handle this use case and was curious which you think best matches the
intentions of the OAuth2 spec.

POSSIBLE APPROACHES:
(1) "Manual Authorization Code" extension.
See description above.

(2) "Client Credentials" with each resource owner registering a separate
client.
We could achieve a similar effect to (1) by using "Client
Credentials".  Say the client is a command-line program
"example-client-cli", which a large number of resource owners have
downloaded and installed.  Each resource owner would register the
client with the authorization server and configure their local install
by telling it the client_id and client_secret.

(3) Something else entirely?

QUESTIONS FOR YOUR:
(Q1) Has the WG thought about this particular use case ("CLI clients")
and do you have a recommended authorization approach.
(Q2) Do Manual Authorization Codes make sense?  Would anyone else find
it useful to have - if I were to write up an extension document for
it?


Thanks in advanced for you help!
Cheers,
Greg Prisament
Software Architect
PowerCloud Systems
___

Re: [OAUTH-WG] Access Token Response without expires_in

[Justin Richer]

Precisely, and without a strong consensus of use in practice today, 
getting the semantics right around a new parameter (even if optional) 
doesn't make sense this late in the game. The information in the token 
response is easily extensible by other documents, and it should go there 
if people really want it to go there.


 -- Justin

On 01/18/2012 08:56 AM, Paul Madsen wrote:

which argues for expressing both explicitly

On 1/17/12 3:58 PM, William Mills wrote:


One use tokens can also expire before they are used.  "You have 5 
minutes to do this once."



*From:* Torsten Lodderstedt [tors...@lodderstedt.net]
*Sent:* Tuesday, January 17, 2012 12:26 PM
*To:* Paul Madsen
*Cc:* oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG
*Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without 
expires_in


Hi Paul,

that's not what I meant. The Client should know which tokens should 
be one time usage based on the API description. The authz server must 
not return expires_in because this would not make any sense in this case.


regards,
Torsten




Paul Madsen  schrieb:

Hi Torsten, yes the use case in question is payment-based as well.

Your suggestion for the client to infer one-time usage from a
missing expires_in contradicts the general consensus of this
thread does it not?

paul

On 1/17/12 11:38 AM, tors...@lodderstedt.net
 wrote:

Hi,

isn't one-time semantics typically associated with certain requests on 
certain resources/resource types. I therefore would assume the client to know 
which tokens to use one-time only. The authz server should not return an 
expires_in paramter. We for example use one time access tokens for payment 
transactions.

What would such an extension specify?

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland

-Original Message-
From: Paul Madsen  
Sender:oauth-boun...@ietf.org  
Date: Tue, 17 Jan 2012 08:23:37
To: Richer, Justin P.  
Cc: OAuth WG  
Subject: Re: [OAUTH-WG] Access Token Response without expires_in

___
OAuth mailing list
OAuth@ietf.org  
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request

[Justin Richer]

+1, sounds reasonable to me and I don't see why not. Also, it fits with 
current implementations that I'm familiar with.


 -- Justin

On 01/20/2012 06:19 PM, Eran Hammer wrote:


The current text:

   If the issued access token scope

   is different from the one requested by the client, the authorization

   server SHOULD include the "scope" response parameter to inform the

   client of the actual scope granted.

Stephen asked why not a MUST. I think it should be MUST. Any disagreement?

EHL



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

[Justin Richer]

Keep in mind that a major purpose of this document is to encourage best 
practices by well-meaning developers. We want to make it clear for 
people who want to do the right thing what the right thing to do is. No 
document in the world will make ill-meaning developers do the right thing.


 -- Justin

On 01/23/2012 07:17 PM, Michael Thomas wrote:

On 01/23/2012 01:47 PM, S Moonesamy wrote:


Minor Issues:

4.4.1.4 2nd bullet.  The explanation of why this wouldn't work for
native clients wasn't comprehensible to me.  I'm suspicious of any
such claims because I can emulate most things a browser can do in a
mobile client.  Perhaps this would be obvious to someone who is an
OAuth2 implementor.


Actually I'd say that it is *not* obvious because I joined the working
group mailing list as an oauth deployer who had precisely questions
along these lines expecting that I was *wrong* in worrying about this
attack.

I'd also say in this section and others like it dealing with native apps
that saying:

   " Assumption: It is not the task of the authorization server to 
protect the end-user's

device from  malicious software"

Is wrong headed. It's not the authorization server's task to protect 
the end user,
but the authorization server *surely* has an interest in protecting 
*itself* from
rogue clients. An attack by a malicious client is an attack against 
the end user

*and* the authorization server.



4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a
Web Browser control embedded in the native app.  If that's not what it
means, I don't understand what it's saying.  If this is true, then the
second bullet point is probably wrong.


I agree, and don't think the first bullet makes any sense either:

   "Native applications SHOULD use external browsers instead of
embedding browsers in an iFrame when requesting end-user 
authorization"


Who exactly is the attacker here? If it's the native app itself, then
this isn't a countermeasure at all because the rogue client will ignore
this SHOULD. If it's not the native app, then what is the an external
browser doing that an embedded browser cannot?

I don't understand the third bullet in this one either, but if only works
in older browsers it's probably not worth mentioning.


Mike
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

[Justin Richer]

My agreement was, and is, to the *production* rules and not the 
*parsing* rules. So long as the former is a proper subset of the latter, 
everything is fine. What's happening here is that the spec is being read 
-- by experts -- as if it were superceding the latter, and that's not a 
good thing.


So as that's the case, I think the solution of using an existing grammar 
by reference but further restricting input to that in the surrounding 
text makes sense to me.


 -- Justin

On 01/25/2012 03:37 AM, Mike Jones wrote:

Eran, do I then correctly understand that you've changed your mind on the position you took in 
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which was: "All I agree 
with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP 
header quoted-string, excluding " and \ so no escaping is needed, ever."?  I ask 
this, because if I correctly understand your statement that you agree with Julian, you are now 
taking the position that you are OK with recipients being required to perform escape 
processing for the scope (and other) parameters and with them being required to accept them 
either as tokens or as quoted strings.

This raises a question I'd like to ask John Bradley, William Mills, Phil Hunt, 
and Justin Richter:  Since all of you replied with a +1 to Eran's original 
statement, are you still in agreement with it, or are you now possibly 
reconsidering your position, as Eran apparently has.  I'm asking, because your 
messages have been part of the basis upon which I've been taking the position 
as editor that the working group consensus is that no quoting may occur.  (The 
other reason that I believed, as editor, that this was a consensus position is 
that this syntax restriction has been present in every Bearer draft, as it was 
in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.)  If 
that's not the actual working group consensus (or it's not anymore), it would 
be good to know that now.

Finally, I'd like to respond publicly to a comment made to me in a private note sent to 
me about the current discussions.  In it, the sender (an IETF "old hand") 
observed that it could appear from the strength of my responses to Julian's feedback that 
I might be trying to defend a particular personal view of how these issues should be 
resolved.  I responded to him that the irony here is that I'm not trying to representing 
a personal position.  Rather, I'm truly trying to do what I believe an IETF editor is 
supposed to do, which is to represent the working group's positions.

I'm quite open to the working group making it clear that its position has 
changed with respect to Julian's comments and equally open to the working group 
standing behind the text in the current draft.  If the chairs would like to 
help bring this issue to successful closure, I would highly welcome their 
participation as well.

Personally, I'd mostly just like to see the spec finished!

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; i...@ietf.org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call:  (The 
OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

I fully agree with Julian's perspective. I believe there is sufficient feedback 
requiring further review of this issue. If the editor cannot facilitate a path 
forward, I request the chairs to intervene.

I will make sure this feedback is fully applied to the MAC token specification 
in the next draft.

EHL



-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Julian Reschke
Sent: Tuesday, January 24, 2012 3:24 PM
To: i...@ietf.org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call:
(The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed
Standard

On 2012-01-23 16:58, Julian Reschke wrote:

On 2012-01-23 16:46, The IESG wrote:

The IESG has received a request from the Web Authorization Protocol
WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
  as a Proposed Standard ...

Please see my comments in

which I think have not been addressed.
...

In an off-list conversation I heard that what I said before may not be
as clear as it could be.

So...

1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.

2) In the IANA considerations, it references the registration
procedure defined in

(now -18, but that doesn't matter here).

3) That document recommends in
:

 o  The parsing of challenges and credentials is defined by this
specification, and canno

Re: [OAUTH-WG] AD Review of -22 (part II)

[Justin Richer]

I realize that -23 is already published with the below text, but since 
this is a whole new section and nobody else seemed to bring it up, I 
wanted to make sure it wasn't missed by the WG.



Suggested non-trivial clarifications:
-

(1) 1.3.4 - "previously arranged" might trigger discusses on the document
since it implies that this spec might not be suited for broad use. I think that
making it clear that the normal mode for client developers is to work against
an existing service (AS and resource server) would help to clarify that such
arrangements are ok here.

Added new 'Interoperability' section to the introduction:

   OAuth 2.0 provides a rich authorization framework with well-defined 
security properties.
   However, as a rich and highly extensible framework with many 
optional components, this
   specification is likely to produce a wide range of non-interoperable 
implementations.
   In addition, this specification leaves a few required components 
partially or fully
   undefined (e.g. client registration, authorization server 
capabilities, endpoint
   discovery).

   This protocol was design with the clear expectation that future work 
will define
   prescriptive profiles and extensions necessary to achieve full 
web-scale
   interoperability.

There is no way to sugar coat reality and hopefully by being blunt about it 
upfront, we will avoid a prolonged debate about the protocol's failings in that 
regard.

I think it's a good idea to call it out, and I don't want to "sugarcoat" 
it either, but the phrase "this specification is likely to produce a 
wide range of non-interoperable implementations" is a bit overdramatic 
in its tone. Instead, I think we should point to other documents that 
are being developed explicitly along side of this, such as at the 
beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest 
text like the following instead:


   OAuth 2.0 provides a rich authorization framework with well-defined
   security properties. However, as a rich and highly extensible
   framework with many optional components, this specification does not
   seek to define all components needed for a fully interoperable
   deployment within this document. Instead, this specification is
   intended to work with complimentary documents that define token
   types [MAC] [Bearer], token formats [JWT] [SAML], client
   registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and
   other considerations.

   This protocol was designed with the clear expectation that future
   work will define prescriptive profiles and extensions necessary to
   achieve full web-scale interoperability.



 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD Review of -22 (part II)

[Justin Richer]

I really don't see it this way, as a failure. Instead, I think we've 
managed to successfully scope the document to address important 
practices and bits of the protocol that will work in tandem with other 
documents to solve different use cases. One of the biggest problems that 
we saw coming in from OAuth1.0 was that it tried to be all things to all 
people all at once, which also didn't help interoperability. I think 
that what we have is a more composable UNIXy approach here. Namely, 
OAuth 2 core/framework/whatever does one thing and does it well: it 
outlines a standard means and structure for getting a token. Does that 
help you use the token against a web service, do service discovery, pack 
information into the token itself? No, but it wasn't meant to. It was 
meant to leave enough space for other docs to take care of that.


But I do not think that it's gone so far as to leave a morass of 
unusable components, much in the way that WS-* did, and I don't think 
the comparison is a fair one. I think the separations are clean and the 
usage profiles are clear.


By pointing developers to other specifications, most of which are 
products of this very working group or members of this working group 
under other umbrellas, we *can* provide a wider view of the world. At 
the absolute least, I think it needs to point to the two token type 
docs, and I'd suggest at least keeping the two token format docs as 
well. And as was pointed out by Phil Hunt, this notion of loosely 
coupled specs and components is actually *beneficial* to today's web 
environment. This is another way that this work differs from WS-*: if 
you're doing one part of WS-*, you're not going to get away without 
doing the rest of it too if you want to have a working system. As you 
point out, and somewhat lament, this is not the case with OAuth 2. You 
can do some parts, and not others, and utalize just the bits that you 
need. The fact that I can use the same endpoints and mechanisms for 
user-delegated auth and machine-directed auth is very powerful, and the 
fact that I can use the same exact client libraries to fetch and use 
both random-hex tokens and signed JWTs is equally powerful. The fact 
that I can reuse 90% of that code and also get signed MAC tokens is 
likewise powerful.


Thus, I stand by my originally-suggested text and respectfully submit it 
to the editor and working group for consideration of inclusion in this 
section.


 -- Justin

On 01/26/2012 12:49 PM, Eran Hammer wrote:



-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 26, 2012 6:07 AM
To: Eran Hammer
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AD Review of -22 (part II)

I realize that -23 is already published with the below text, but since this is a
whole new section and nobody else seemed to bring it up, I wanted to make
sure it wasn't missed by the WG.
I think it's a good idea to call it out, and I don't want to "sugarcoat" it 
either,
but the phrase "this specification is likely to produce a wide range of non-
interoperable implementations" is a bit overdramatic in its tone. Instead, I
think we should point to other documents that are being developed explicitly
along side of this, such as at the beginning of RFC2904
(http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:

OAuth 2.0 provides a rich authorization framework with well-defined security
properties. However, as a rich and highly extensible framework with many
optional components, this specification does not seek to define all
components needed for a fully interoperable deployment within this
document. Instead, this specification is intended to work with complimentary
documents that define token types [MAC] [Bearer], token formats [JWT]
[SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD],
and other considerations.
This protocol was designed with the clear expectation that future work will
define prescriptive profiles and extensions necessary to achieve full web-
scale interoperability.

This does sugarcoat the fact that 2.0 does not provide *any* guaranteed 
interoperability. The implementations I've seen so far have simply adopted a 
*profile* of this document along with bearer tokens. We've already seen 
feedback on this list where client developers were surprised and frustrated 
with such implementations when trying to reuse code across providers and this 
is only going to get more noticeable. And then of course we have the insane 
complexity of the over-architected solutions, adding layer after layer to solve 
problems that are as simple as making a parameter required and well specified.

We've also seen questions about providers looking to claim OAuth 2.0 support 
while maintaining all their existing architecture and security properties, 
seeking to push the boundaries of what is permitted by t

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2

[Justin Richer]

+1 for consistent examples.

 -- Justin

On 02/06/2012 02:35 PM, Eran Hammer wrote:


Sending to the right place.

*From:*Thomas, Christopher (LLU) [mailto:cwtho...@llu.edu]
*Sent:* Monday, February 06, 2012 11:33 AM
*To:* draft-ietf-oauth...@tools.ietf.org
*Subject:* Mail regarding draft-ietf-oauth-v2

Hello,

I'm looking into implementing the Oauth2 spec for a work project and I 
think I ran into an issue with the version 23 documentation. According 
to the Oauth2 documentation, a client can send it's credentials one of 
two ways: 1) via HTTP Basic Auth 2) via the request body parameters. 
Section 2.3.1 says "the HTTP Basic authentication scheme as 
defined in [RFC2617] to authenticate with the authorization server.  
The client identifier is used as the username, and the client password 
is   used as the password."


The example given in Section 2.3.1 is:

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

According to RFC2617 Section 2, the value of the credential is a 
base64 representation of "username:password" (no quotes). This means 
when the value is decoded, it is "s6BhdRkqt3:gX1fBat3bV". So, 
according to the HTTP Basic Auth example, the client_id is s6BhdRkqt3 
and the client_secret is gX1fBat3bV. Just below the basic auth example 
is the request body example:


POST /token HTTP/1.1

 Host: server.example.com

 Content-Type: application/x-www-form-urlencoded;charset=UTF-8

 grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

In the request body example, the client_secret does not match the 
client_secret in the HTTP Basic Auth example. I think the two should 
match for consistency. I propose the change that is in the patch 
attached to this email.


Thank you for considering my suggestion.

Chris

Christopher Thomas, BA --- Systems Analyst/
/LOMA LINDA UNIVERSITY | Information Systems

Loma Linda University, Loma Linda, California 92350
x87866 or (909) 558-7866



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23

[Justin Richer]

Responses inline. Don't know if you want to forward these to the 
appropriate other lists/authors as well.


On 02/07/2012 01:04 PM, Eran Hammer wrote:


-Original Message-
From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk]
Sent: Tuesday, February 07, 2012 9:31 AM
To: apps-disc...@ietf.org; barryle...@gmail.com; dick.ha...@gmail.com; 
d...@fb.com; Eran Hammer; hannes.tschofe...@gmx.net; stephen.farr...@cs.tcd.ie
Cc: i...@ietf.org
Subject: Appsdir review of draft-ietf-oauth-v2-23

I have been selected as the Applications Area Directorate reviewer for this 
draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you may 
receive. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

Document: draft-ietf-oauth-v2-23

Title: The OAuth 2.0 Authorization Protocol

Reviewer: Henry S. Thompson

Review Date: 2012-02-07

IETF Last Call Date: 2012-01-24

Summary: This draft is almost ready for publication as an Proposed
  Standard but has a few issues that should be fixed
  before publication

[Note - My expertise is in the areas of markup and architecture, with only the 
average geek's understanding of security and cryptographic technologies.  Any 
comments below on security issues are therefore of the nature of general 
audience concerns, rather than technical worries.]

Major Issues:

3.1.2.1  The failure to require TLS here is worrying.  At the very least I 
would expect a requirement that clients which do _not_ require TLS MUST provide 
significant user feedback calling attention to this
-- by analogy, absence of a padlock does _not_ suffice. . .


There are two bits going on here, and I think there's confusion again 
about this being a *client* controlled endpoint. First, not all callback 
redirects are remote HTTP URLs. A http://localhost/ callback or an 
app:// callback are going to be very common with installed clients, and 
in both of these cases TLS makes no sense to require. Second, and this 
is the reason spelled out in the text, you can't really expect all 
*clients* to use proper TLS on their redirects. If it's a remote HTTP 
call, then it's likely a very Bad Idea to go over a plaintext socket, 
yes. But there are enough other cases where mandating it doesn't make 
sense.


Suggestion: call out second non-HTTP use case here as well, perhaps stop 
calling it an "endpoint" to differentiate it from the server-side pieces.



2.1.2.5  In a somewhat parallel case, I would expect this section to at least 
explain why the SHOULD NOT is not a MUST NOT. Since in practice the distinction 
between trusted and untrusted 3rd-party scripting is difficult if not 
impossible to draw, as written the 2nd para is effectively overriden by the 
third.

Assuming this means 3.1.2.5

A MUST NOT is impossible to enforce here. You're telling people to not 
include jQuery in their JavaScript app. Truth is, any third party 
library that you include in your app could get access to the security 
bits whether it's on the callback page or not. I think it's appropriate 
to provide guidance for best practices here, and the MUST be first and 
SHOULD be only makes sense. People will get it wrong in spite of what 
the spec says here one way or another.


Suggestion: drop the requirements (and move them to the security doc), 
or otherwise no change.



11  It seems at best old-fashioned that the designer of a new access token 
type, parameter, endpoint response type or extension error has no better tool 
available than Google to help him/her discover whether the name they have in 
mind is in use already.  The same is true under the proposed approach for any 
developer trying to determine what they can use or must support.  Is there some 
reason that mandated URI templates, after the fashion of

   http://www.iana.org/assignments/media-types/text/...

are not mandated for the registries, e.g.

   http://www.iana.org/assignments/access-token-types/bearer

?  If there is a good reason, please use it to at least explicitly acknowledge and 
justify the basis for failing to provide a way for users and developers to use the 
"follow your nose" strategy [1].  If there is no good reason, please include 
the appropriate language to require something along the lines suggested above.  If you 
need a model, see [2].


I'm confused - is this a request to use a full URI for all extension 
values? I thought the purpose of a registry was to deconflict the short 
names, and that URIs could be used for anything else.



Minor Issues:

A short summary of the changes from OAuth 1.0/RFC5849 would have been helpful, 
and it might still be a good idea to add one. . .


I don't think this is possible. OAuth2 is built fundamentally 
differently from OAuth1, so this paragraph might as well read "just 
about everything but the concept". Suggestion: don't add 

Re: [OAUTH-WG] Clarification on section 3.3: missing scope parameter in access token request

[Justin Richer]

In most cases, it will likely be a fixed value, but there's nothing 
indicating that it can't be contextual. Especially in cases where you've 
got public, confidential, and dynamically-registered clients all acting 
on the same host, the default value will depend completely on what kind 
of client is asking.


Really, this is a way of saying "scope is up to the AS", which it is, 
even if the client asks for something else.


 -- Justin

On 02/12/2012 11:44 PM, Andrew Arnott wrote:

From section 3.3 (draft 23):

If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using*a pre-defined default value*, or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined). 



Is this saying that the pre-defined default value must be a FIXED 
value for all clients and all grants?  Or might the predefined default 
value actually be a derivation of the grant? (for example, by default 
the access token scope is simply the maximum scope allowed by the grant)


Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23

[Justin Richer]

On 02/15/2012 04:33 AM, Songhaibin wrote:

I've reviewed this document as part of the transport area directorate's ongoing 
effort to review key IETF documents. These comments were written primarily for 
the transport area directors, but are copied to the document's authors for 
their information and to allow them to address any issues raised. The authors 
should consider this review together with any other last-call comments they 
receive. Please always CC tsv-...@ietf.org if you reply to or forward this 
review.

First, I should apologize for the delay in this review, I should have finished 
it two days ago. I have some common security knowledge but not an expert.

Summary

This draft is basically ready for publication, but has nits that should be 
fixed before publication.

General issues need discussion:

1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password 
credentials, and client credentials. These two have the same flow and many in common, and they are 
significantly different than the authorization code grant type and implicit grant type described in 
previous sections. And in section 1.3.4, it also says " Client credentials are used as an 
authorization grant typically when the client is acting on its own behalf (the client is also the 
resource owner),...". Is it better to combine these two grant types as one "client 
credentials" grant type where the client can be the resource owner?


No, they are quite distinct -- It all comes down to what you're 
authenticating. The Resource Owner Password Credentials flow *also* 
includes client credentials which are distinct from the resource owner's 
own credentials. The client's credentials are going to be the same for a 
given client across many different users, while the Resource Owner's 
credentials are going to be different across different users, but the 
same across different clients (for the same resource owner). In most 
flows, the client's credentials identify just the client, and the 
resource owner is identified through some other means (a direct 
password, a redirected login to the authz endpoint). In the Client 
Credentials flow, the client's credentials are the only ones that you have.



2. Two concepts confused me in section 2.4, I don't know if I am the only 
person who is confusing here. One is user-agent-based application and another 
is native application, why are they executed on the device used by the resource 
owner? I think they can run on any device used by resource consumer instead of 
resource owner. Resource owner is only used to grant access to resources.


OAuth's main 3-legged pattern allows what's called "Alice-to-Alice 
sharing", in that the Client is consuming on behalf of the resource 
owner. In cases where you have an in-user-agent app or a native app, the 
end user (resource owner) is going to be the one running it, and the one 
authorizing it.



Thanks for your feedback, and I hope this can help clear up the intent 
of the working group here. If you can suggest language that will 
solidify these points further, it can help make sure this doesn't 
further confuse people.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Securing APIs with OAuth 2.0

[Justin Richer]

+1 to André's suggestion below.

If you find that you're going to have to add a field to your API to 
indicate the userID along with a two-legged transaction, you're likely 
doing things wrong.


We've used the auto-approve method below for several applications, and 
users don't seem to know or care what's really happening. They show up 
to the client app, they see a little waiting screen the first time 
through, and then it works. That is to say, it's nearly as transparent 
as a two-legged scenario but with better security and flexibility aspects.


The two-legged approach works best when:
  1) There's no user involved in the transaction at all (traditional 
system-to-system data exchange)
  2) You *can't* have the user present on any part of the transaction 
(it must work fully back-channel)


If you can count on the user being there at any point, even to just kick 
things off, then the code flow is likely more like what you're after.


 -- Justin

On 03/01/2012 05:24 PM, André DeMarre wrote:

Pete,

Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site) will be using the API
(OAuth auth/resource server) to access user-specific resources, then
the authorization code grant type is a better fit. It doesn't matter
that the OAuth server trusts the client without needing user
authorization.

The authorization code flow offers a solution for user identification
that is absent in the client credential flow. In other words, even
though the OAuth server trusts the client and will comply with all API
requests, how is the client x supposed to identify a user so it can
request the right resource from the resource server?

By using an authorization code grant, the client can acquire an access
token that is bound to a specific user. This is makes the
authorization code flow suitable for single sign-on implementations,
whereas the client credential flow is not appropriate for user
authentication.

Don't worry about the fact that the client does not need to be
authorized by the user. You can still use the authorization code flow,
and the authorization server will not need to prompt the user for
authorization because you will have pre-authorized the client for all
users.

As an added bonus, this sets you up perfectly for when you add new
clients which are not pre-authorized and need user authorization.

I hope that helps.

Regards,
Andre DeMarre

On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden  wrote:

1. Yes, client credentials sounds right for what you described. Think of it
as lightweight b2b authentication in that sense (but two steps - one to get
a token, and another to use it).
2. Can't help you with source - but do have a product-based solution :)
3. Absolutely it should for the resource server, but the answer may depend
have same dependency on the implementation you use.

Regards,
Shane.



From:   Pete Clark
To: "oauth@ietf.org"
Date:   29/02/2012 06:50 PM
Subject:[OAUTH-WG] Securing APIs with OAuth 2.0
Sent by:oauth-boun...@ietf.org



Hey all, I've joined the list because I'd like to use OAuth 2 to implement
security for a new set of REST APIs I'm developing for a client.  I'm
coding with PHP, but my questions are more general.  Right now, there will
be only one web site that uses the APIs, in a server-to-server fashion, and
currently we don't have a need for a third party application to gain access
to user data, such that a user would need to authorize that app.  We do,
however, want to have that ability down the road.  My question is, can I
still use OAuth 2 in some way to implement our first phase?  From what I've
read, it seems like the "client credentials" flow is the one I want to use
for now.  Can someone:

1) Confirm that that's what I should use for this first phase?
2) Point me to an implementation of this flow (in any language) that I
could use or port to PHP?  I've found some libraries for php but can't
really tell, being new, if they offer the "client credentials" flow
3) Answer one more question.. Will using the client credentials flow now
allow me to move to one of the user-authorizes-external-app flows down the
road without having to reimplement or throw away the client credentials
flow code?

I apologize for all the questions, but these would really help point me in
the right direction.. Thank you for reading!

Sincerely,
Pete



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.

Re: [OAUTH-WG] Securing APIs with OAuth 2.0

[Justin Richer]

Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site) will be using the API
(OAuth auth/resource server) to access user-specific resources, then
the authorization code grant type is a better fit. It doesn't matter
that the OAuth server trusts the client without needing user
authorization.

The authorization code flow offers a solution for user identification
that is absent in the client credential flow. In other words, even
though the OAuth server trusts the client and will comply with all API
requests, how is the client x supposed to identify a user so it can
request the right resource from the resource server?

By using an authorization code grant, the client can acquire an access
token that is bound to a specific user. This is makes the
authorization code flow suitable for single sign-on implementations,
whereas the client credential flow is not appropriate for user
authentication.

Don't worry about the fact that the client does not need to be
authorized by the user. You can still use the authorization code flow,
and the authorization server will not need to prompt the user for
authorization because you will have pre-authorized the client for all
users.



Can the authorization server return a (pre-authorized) token 
immediately in this case, despite the fact the client is specifying 
"response_type=code" ?
No -- the server MUST return an authorization code, even if there is no 
interaction beyond the user logging in (which may be SSO and therefore 
"invisible" to users). This code is bound to the user session and the 
client ID, and it needs to be presented in the back channel with the 
client's ID and secret, away from the user session. These two steps are 
what close the client-server-user triangle in a secure way so that no 
party knows more than they really need to. The Client Credentials flow 
and the Implicit flow collapse this triangle into a line in two 
different ways, both for different use cases and both have their 
tradeoffs. So if you want to get an access token from the authz endpoint 
directly, you use the implicit flow. It puts all of the weight onto the 
user agent, which sounds like the opposite of what you actually want to 
do here.


If the authorization code, to be exchanged later for this token, has 
to be returned, how reasonable is it to expect that the authorization 
code will be bound to the pre-authorized access token (example, the 
access token's key/id will be returned as the authorization code) ?


I suspect it may not be a good idea given the spec is saying the 
authorization code should be short-lived, thus the codes and actual 
tokens will have different life-cycles, however the fact the end user 
has pre-authorized the client adds some uncertainty to it...


Again, no -- the code shouldn't have anything in it that ties it to the 
access token directly. If it did, then anybody intercepting just the 
code on the wire could guess the access token, which would make the auth 
code a pointless abstraction. The best way to deploy the authz code is 
to have a short, random, opaque blob that is one-time use and expires 
after a set amount of time, probably fairly short (on the order of 
minutes in most cases). Think of it as a one-time-password that is 
generated for the resource owner to give to the client on their behalf. 
Since it's a credential known to both the user agent and the client, you 
really, really don't want it to be copied from any other part of the flow.


 -- Justin



thanks, Sergey


As an added bonus, this sets you up perfectly for when you add new
clients which are not pre-authorized and need user authorization.

I hope that helps.

Regards,
Andre DeMarre

On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden  
wrote:
1. Yes, client credentials sounds right for what you described. 
Think of it
as lightweight b2b authentication in that sense (but two steps - one 
to get

a token, and another to use it).
2. Can't help you with source - but do have a product-based solution :)
3. Absolutely it should for the resource server, but the answer may 
depend

have same dependency on the implementation you use.

Regards,
Shane.



From:   Pete Clark
To: "oauth@ietf.org"
Date:   29/02/2012 06:50 PM
Subject:[OAUTH-WG] Securing APIs with OAuth 2.0
Sent by:oauth-boun...@ietf.org



Hey all, I've joined the list because I'd like to use OAuth 2 to 
implement

security for a new set of REST APIs I'm developing for a client.  I'm
coding with PHP, but my questions are more general.  Right now, 
there will
be only one web site that uses the APIs, in a server-to-server 
fashion, and
currently we don't have a need for a third party application to gain 
access
to user data, such that a user would need to authorize that app.  We 
do,
however, want to have that ability down

Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

[Justin Richer]

I think clarification text makes sense here because we're importing a 
term from a foreign spec -- b64token -- that overlaps with a term 
meaning something quite different in our spec -- token. We can't really 
change either of these terms, so we need to separate them some other way.

 -- Justin

On 03/06/2012 11:29 AM, Paul Madsen wrote:

as one of the unnamed 'confused colleagues', I'd welcome clarification

paul

On 3/6/12 11:23 AM, Brian Campbell wrote:

Thanks Mike, I think changing the example would be helpful.

However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.

I can propose some specific text (building on James') if others in the WG agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones  wrote:

I'm fine with changing the example to make it clearer that b64token allows a 
wider range of characters than just those legal for base64 and base64url 
encodings of data values.

I'll add it to my to-do list for any additional edits for the Bearer spec.

-- Mike

-Original Message-
From:oauth-boun...@ietf.org  [mailto:oauth-boun...@ietf.org] On Behalf Of 
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in 
draft-ietf-oauth-v2-bearer

Brian,


On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.

Do I read this correctly?

Yes.


If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some 
confusion by showing that it does not have to be base64 encoding. How about 
changing:
  Authorization: Bearer vF9dft4qmT
to
  Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how 
OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" 
member of an access token response is the bearer token. The "access_token" string value (after 
unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such 
text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined.



Also, does the use of b64token implicitly limit the allowed characters
that an AS can use to construct a bearer access token?

Yes.



*http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
**
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

--
James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Securing APIs with OAuth 2.0

[Justin Richer]

OK.

Thanks for the explanations so far. It's very helpful.

I'm prototyping the framework support for OAuth 2.0 and at this stage
I'm trying to figure out what exactly the runtime itself can do and what
has to be delegated to the custom code and thus how to design the api
the runtime and the custom code will use to communicate with each other.


Makes sense. It's often hard to figure out exactly where to draw the 
lines of abstraction for fundamental libraries like this.



Let me ask one more question, sorry if it's a silly one :-)

So suppose a given client has been pre-authorized by the end user.
Next, the client can get the pre-authorized token via the authorization
code flow or the implicit code flow (ignoring the client_credentials one
for the moment).

Does it make sense to restrict which flow a given pre-authorized token
can 'work' with ? Example, enforce that the pre-authorized token can
only be issued to the clients initiating an authorization code flow but
not to those trying an implicit one, or vice versa ?

The reason I ask is that I'm thinking that the entity representing an
access token should have a property indicating which grant type was used
for this token being created in the first place. So if such a token
were to represent the user pre-authorizing the client
and then eventually given to a client via the authorization code or
implicit code flow, then this token would actually need to
be cloned each time for a specific grant type property be set, and
this does not look optimal...


Several implementations that I've seen do restrict the flows that a 
given client is allowed to do. Any time you have a privileged client, 
such as one that's been auto-approved, it makes even more sense to lock 
it down in other avenues. You don't have to encode it into the token or 
code, but of course if you have a structured token format you may do 
that. Note that with the code flow, you probably don't actually generate 
the token until the client shows up with a valid code and client 
id/secret, but that's really a runtime optimization that's going to be 
specific for your setup.


All you really need is a flag at your AS that ties the given client id 
to a set of allowable grant types. When the client shows up at the AS 
endpoints, you look up this flag based on the client ID and verify that 
the flow you're doing matches up with what's allowed by configuration.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

[Justin Richer]

Makes sense to me, except that I think the token_type value is typically 
lowercase "bearer", though it's defined to be case insensitive in 
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the 
value of this field for the Bearer token type ever got defined anywhere. 
Section 7.1 references the bearer spec as defining the value of the 
"token_type" parameter, and passes its example as if by reference. Would 
be worthwhile giving an example of a token endpoint response, such as 
what's found in OAuth-v2-23 section 5.1.


 -- Justin

On 03/07/2012 12:16 PM, Brian Campbell wrote:

I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec.  I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.


==>  Insert the following text at the beginning of §2:

To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access
token response is "Bearer", the string value of the "access_token"
parameter becomes the bearer access token used to make protected
resource requests.

==>  Change the value of the token in the Authorization header example to this:

Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b

==>  Insert the following text before the last paragraph of §2.1:

Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.


Thanks,
Brian




On Tue, Mar 6, 2012 at 11:45 AM, William Mills  wrote:

Yeah, something as simple as, "Note that the name 'b64token' does not imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would do
it.

-bill


From: Brian Campbell
To: Mike Jones
Cc: oauth
Sent: Tuesday, March 6, 2012 8:23 AM

Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer

Thanks Mike, I think changing the example would be helpful.

However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.

I can propose some specific text (building on James') if others in the WG
agree?


On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones
wrote:

I'm fine with changing the example to make it clearer that b64token allows
a wider range of characters than just those legal for base64 and base64url
encodings of data values.

I'll add it to my to-do list for any additional edits for the Bearer spec.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer

Brian,


On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
however, I see that b64token is just an ABNF syntax definition
allowing for characters typically used in base64, base64url, etc.. So
the b64token doesn't define any encoding or decoding but rather just
defines what characters can be used in the part of the Authorization
header that will contain the access token.

Do I read this correctly?

Yes.


If so, I feel like some additional clarifying text in the Bearer
Tokens draft might help avoid what is (based on my small sample) a
common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some
confusion by showing that it does not have to be base64 encoding. How about
changing:
  Authorization: Bearer vF9dft4qmT
to
  Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't
quite manage to be precise about how OAuth and Bearer connect. It could
explicitly state that the string value of the "access_token" member of an
access token response is the bearer token. The "access_to

Re: [OAUTH-WG] OAuth WG Re-Chartering

[Justin Richer]

I think it's a matter of politics and semantics: The real question is 
what do we officially build the IETF version off of? The WG can't 
officially start with the OIDF document due to IETF process, which makes 
sense. But there's nothing that says we can't start with Thomas's draft 
and be heavily influenced by the Connect draft, and make a new one as a 
real starting point for conversation.


If the Connect implementation still needs specific things, it can extend 
or profile the IETF version, and remain an OIDF document that 
normatively references the IETF document. This is where I see some real 
value -- the WG can focus on making a solid interoperable registration 
piece that different applications can extend and use as they see fit for 
the particulars of their use cases.


Does this pass muster with everyone?

 -- Justin

On 03/22/2012 01:26 PM, Mike Jones wrote:
I agree with John that submitting the OpenID Connect dynamic client 
registration spec to the IETF would make no sense.  It is 
intentionally specific to the requirements of the Connect use case.


I sent the link to it only so people could compare them, if interested.

-- Mike

From: John Bradley
Sent: 3/22/2012 9:43 AM
To: Phil Hunt
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

It is a OIDF spec at the moment.  We don't have any plan to submit it 
currently.


If there is a WG desire for that to happen the OIDF board would have 
to discuss making a submission.


All in all I don't know that it is worth the IPR Lawyer time, as 
Thomas has a quite similar ID Submission.


Anything is possible however.

John B.
On 2012-03-22, at 1:24 PM, Phil Hunt wrote:

Would the plan be for the Connect Registration spec to be submitted 
to IETF so they can become WG drafts?


The spec seems like a good starting point.

Phil

@independentid


[The entire original message is not included.]


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on Assertion Drafts

[Justin Richer]

http://tools.ietf.org/html/draft-ietf-oauth-assertions-01



Section 7's second portion about a client including multiple credentials 
types seems buried down here in the Error Responses section for 
something this fundamental. It also conflates discussion of selection of 
this client authorization type in here, where it ought to be in its own 
section, closer to the top.



http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02



This one seems fine to me, very straightforward.


http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10



As I try to avoid SAML in general, I'm not a good person to comment on 
this draft.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

[Justin Richer]

   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  In some cases, the "scope" value will be used
   when requesting a new access token with sufficient scope of access to
   utilize the protected resource.  The "scope" attribute MUST NOT
   appear more than once.  The "scope" value is intended for
   programmatic use and is not meant to be displayed to end users.

I don't think this provide enough information about what this is, how 
it is to be used and which values are allowed. As this is not meant to 
be displayed to end users, then you need to say what values are 
allowed and which entity can allocate them. Is there a registry for 
these tokens, e.g. an IANA registry?


The editor provided explanation in email, however this was not 
reflected in any version of the draft.


Scopes are service specific and as such their values and semantics are 
defined by each individual authorization server and are not coordinated 
through any centralized repository, registry, or standards body. So long 
as it fits the syntax defined by the grammar, any string is allowed.




2). Section "3.1.  Error Codes"

I've suggested to use an IANA registry for this field. Apparently 
there is already a registry created by 
. 
However this document doesn't register values defined in section 3.1 
with IANA and doesn't point to draft-ietf-oauth-v2-23 for the 
registry. I find this to be very confusing.


Seems like there should be a simple pointer to OAuth2 section 8.5 or 
11.4 here, and "insufficient_scope" does need to be registered, doesn't 
it? Though these are errors coming from the PR and not the token 
endpoint, so maybe they all need to be registered.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

[Justin Richer]

If the mobile device has a web browser (such as a smart phone), then 
this is pretty easy, and you've got a couple of options.


One of the best options when the token is on behalf of an end user is, 
in my opinion, to use the authorization code flow like this: First, 
register what's called a "public client" with your server -- so you'll 
get an ID but not a client secret. With that client ID, register a 
custom-scheme callback URI, like "myapp://oauthcallback", and register 
your app on the device as the handler for "myapp".


In your application, to start things off, you fire off a web browser to 
the authorization server's authorization endpoint. The user logs in to 
the authorization server through the web browser, approves this copy of 
your app, and gets redirected to "myapp://oauthcallback?code=basdf132". 
Your app grabs the "myapp://" url and plucks the authorization code off 
the end of it. Your app then takes that code and sends it in the 
background to the token endpoint to exchange for a token.


Some key points:

1) You need to have access to a web browser on the platform, and it's 
considered best practice to push the user to the external browser 
application on the platform instead of embedding one. There are a couple 
paragraphs in the spec's security considerations section that talk about 
this.
2) Your app is "public" because you can't publish it with a secret at 
configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the 
device -- they need to be in a trusted space where other apps on the 
device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on 
the way through, so make sure your codes are all one time use and short 
lived.


None of this is just theoretically possible, people are doing it today. 
What libraries and stuff you'd be after depends wholly on your platform 
(both server and client side).


 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:


Hi all,

I've been talking to some of you off line about this already, but I 
need some help in terms of implementation.  I would like to use OAuth 
as a means to get either a JWT or SAML token to a client running on a 
handheld device.  This is something that I'm looking to prototype (as 
part of a larger project) beginning this week.  So, it is important to 
me to understand the divide between what is theoretically possible and 
what is actually possible.


Anybody aware of any implementations out there, either vendor or open 
source, that I can use for this?


Tx!
adam



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Justin Richer]

Did the "Introspection Endpoint" or "Methods for connecting a PR to an 
AS" get dropped? There seemed to be interest in the list in coming up 
with a generally applicable scheme, or set of schemes, to do this, and 
there are certainly no shortage of starting points. Both AOL and Ping 
have their own token introspection drafts that got put to the list, 
we've developed our own internal approach here, UMA has an alternative 
approach, and OpenID Connect has invented its own approach for ID Tokens.


I just want to make sure that this was an explicit decision of it being 
out of scope here and not an inadvertent omission.


 -- Justin

On 04/12/2012 06:55 AM, Hannes Tschofenig wrote:

Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am 
going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content 
(particularly the suggested milestone dates):

--


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token 
with
the SAML 2.0 bearer assertion profile.  This offers interworking with existing
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service 
provider
community. To build on this success we aim for nothing more than to make OAuth 
the
authorization framework of choice for any Internet protocol. Consequently, the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth 
specification
truly is an important building block it relies on other specifications in order 
to
claim completeness. Luckily, these components already exist and have been 
deployed
on the Internet. Through the IETF standards process they will be improved in
quality and will undergo a rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working 
group item
Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for 
consideration as a Proposed Standard
Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are 
they realistic?]

May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the 
IESG for consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration 
as a Proposed Standard
May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for 
consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the 
IESG for consideration as an Informational RFC
Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: New work for the group]

Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a 
Pr

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Justin Richer]

OK, but with SWD and discovery off the table, can this now be considered 
to be within that manageable number instead?


 -- Justin

On 04/13/2012 01:10 PM, Mike Jones wrote:

Yes, there was an explicit decision in that regard.  My sense was that the WG 
did think they're important but they only wanted to take on a manageable number 
of tasks at once.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Friday, April 13, 2012 10:02 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS" get 
dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, 
or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and 
Ping have their own token introspection drafts that got put to the list, we've developed our own 
internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own 
approach for ID Tokens.

I just want to make sure that this was an explicit decision of it being out of 
scope here and not an inadvertent omission.

   -- Justin

On 04/12/2012 06:55 AM, Hannes Tschofenig wrote:

Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am 
going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content 
(particularly the suggested milestone dates):

--


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user sharing his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth
2.0 to incorporate implementation experience with version 1.0,
additional use cases, and various other security, readability, and
interoperability improvements. An extensive security analysis was
conducted and the result is available as a stand-alone document
offering guidance for audiences beyond the community of protocol implementers.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token as well as the message authentication
code (MAC) access authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
token with the SAML 2.0 bearer assertion profile.  This offers
interworking with existing identity management solutions, in particular SAML 
based deployments.

OAuth has enjoyed widespread adoption by the Internet application
service provider community. To build on this success we aim for
nothing more than to make OAuth the authorization framework of choice
for any Internet protocol. Consequently, the ongoing standardization
effort within the OAuth working group is focused on enhancing
interoperability of OAuth deployments. While the core OAuth
specification truly is an important building block it relies on other
specifications in order to claim completeness. Luckily, these
components already exist and have been deployed on the Internet. Through the 
IETF standards process they will be improved in quality and will undergo a 
rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a
working group item Done  Submit 'HTTP Authentication: MAC
Authentication' as a working group item Done  Submit 'The OAuth 2.0
Protocol: Bearer Tokens' to the IESG for consideration as a Proposed
Standard Done  Submit 'The OAuth 2.0 Authorization Protocol' to the
IESG for consideration as a Proposed Standard

[Editor's Note: Finishing exist

Re: [OAUTH-WG] IIW and OAuth

[Justin Richer]

Thursday would conflict with IIW sessions proper, and we'd prefer a 
Friday morning get together.


 -- Justin

On 04/16/2012 12:27 PM, John Bradley wrote:

Thursday morning works for me as well.

John B.

Sent from my iPad

On 2012-04-16, at 6:14 PM, Phil Hunt  wrote:


Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys,

I was wondering how many of you will be at the upcoming IIW in Mountain View 
(or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 
3rd).

I thought it might be good to useful to get together on the Friday after the 
IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them 
out of the door.
(And thanks to those who have already read them.)

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Justin Richer]

OK, but with SWD and discovery off the table, can this now be
considered to be within that manageable number instead?

We wanted to keep the # of WG items to approximately 5.  Once we finish
some of these items and get them off our plate we could roll new items
onto the plate, theoretically.



That's definitely true going forward, but what I was saying is that the 
number of items under consideration is now down to 4, with SWD moving to 
the Apps group. I was proposing that the whole introspection endpoint 
and general AS-PR connection could be this group's fifth starting document.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IIW and OAuth

[Justin Richer]

It was also my understanding that this was for something outside of IIW, 
in addition to whatever happens *at* IIW. Nothing's stopping there being 
various IIW sessions on topic as well, but there's something to be said 
for getting together for a few hours at a shot without the distractions 
of the rest of the unconference going on simultaneously.


It's worked well before.

 -- Justin

On 04/16/2012 06:28 PM, John Bradley wrote:

I only purchased the Tuesday for IIW because I am tied up Wednesday and 
Thursday is traditionally digital death or something like that.

Tuesday is best if it is going to be during IIW hours.  Though I thought Hannes 
was suggesting something outside IIW.

John B.
On 2012-04-17, at 12:21 AM, Mike Jones wrote:


I propose that you schedule this session at IIW on Thursday, as that looks like 
the time that will garner the greatest participation.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
axel.nenn...@telekom.de
Sent: Monday, April 16, 2012 10:55 AM
To: phil.h...@oracle.com; hannes.tschofe...@gmx.net
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] IIW and OAuth

Same for me. Tues-Thurs works better for me too.
Axel

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Monday, April 16, 2012 6:15 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] IIW and OAuth

Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys,

I was wondering how many of you will be at the upcoming IIW in Mountain View 
(or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 
3rd).

I thought it might be good to useful to get together on the Friday after the 
IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them 
out of the door.
(And thanks to those who have already read them.)

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Client Registration

[Justin Richer]

So it's a "known issue". I think that's an artificial reason to leave it 
and a reasonable section to be cut out first.


 -- Justin

On 04/18/2012 03:51 PM, Eran Hammer wrote:

Because it is in the draft the WG is suppose to consider. It's a stated 
dependency.

EH


-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, April 18, 2012 12:50 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration

Hi Eran,

why do you see a relationship between dynamic client registration and
discovery? Basically, we don't care so far how a client finds tokens and end-
user authorization point. Why is this any different for the client registration
endpoint (or the revocation endpoint)? Or do you have a bigger picture in
mind?

regards,
Torsten.

Am 15.04.2012 22:36, schrieb Eran Hammer:

Where did I say I'm not interested in this work?!

All I was saying is that it would be better to postpone it until the discovery

layer, which this draft clearly relies upon, is a bit clearer. I would be 
satisfied
with a simple note stating that if the discovery work at the APP area isn't
complete, the WG may choose to delay work on this document until ready.

EH


-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Sunday, April 15, 2012 9:01 AM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration

Hi Eran,

you are saying that you are not interested in the dynamic client
registration work and that's OK. There are, however, a couple of
other folks in the group who had expressed interest to work on it, to

review and to implement it.

Note also that the discovery and the dynamic client registration is
different from each other; there is a relationship but they are

nevertheless different.

Ciao
Hannes

PS: Moving the Simple Web Discovery to the Apps area working group
does not mean that it will not be done. On the contrary there will be
work happing and we are just trying to figure out what the difference
between SWD and WebFinger is.

On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote:


I'd like to see 'Dynamic Client Registration' removed from the
charter along

with SWD for the sole reason that figuring out a generic discovery
mechanism is going to take some time and this WG has enough other
work to focus on while that happens elsewhere. I expect this to come
back in the next round with much more deployment experience and

discovery clarity.

EH


-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Hannes Tschofenig
Sent: Friday, April 13, 2012 7:36 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Dynamic Client Registration

Hi all,

at the IETF#83 OAuth working group meeting we had some confusion
about the Dynamic Client Registration and the Simple Web Discovery
item. I just listened to the audio recording again.

With the ongoing mailing list discussion regarding WebFinger vs.
Simple Web Discovery I hope that folks had a chance to look at the
documents again and so the confusion of some got resolved.

I believe the proposed new charter item is sufficiently clear with
regard to the scope of the work. Right?
Here is the item again:
"
Jul. 2013  Submit 'OAuth Dynamic Client Registration Protocol' to
the IESG for consideration as a Proposed Standard

[Starting point for the work will be
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg
]
"

Of course there there is a relationship between Simple Web
Discovery (or
WebFinger) and the dynamic client registration since the client
first needs to discover the client registration endpoint at the
authorization server before interacting with it.

Now, one thing that just came to my mind when looking again at
draft- hardjono-oauth-dynreq was the following: Could the Client
Registration Request and Response protocol exchange could become a
profile of the SCIM protocol? In some sense this exchange is
nothing else than provisioning an account at the Authorization
Server (along with

some meta-data).

Is this too far fetched?

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Justin Richer]

Not all implementations in the field that do this are using JWTs as the 
tokens. Ours in particular used a random blob with no structured 
information in it. The endpoint returned a JSON object.


 -- Justin

On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:

Hi all,

is there enough experience in the field with such an interface to 
standardize it?


I would expect such an endpoint to return the same payload, which is 
carried in a JSON Web Token. So once we designed the JSON Web Tokens 
content, designing the AS-PR interface could be the next logical step 
(after the next re-charting).


regards,
Torsten.

Am 16.04.2012 21:04, schrieb Justin Richer:



OK, but with SWD and discovery off the table, can this now be
considered to be within that manageable number instead?

We wanted to keep the # of WG items to approximately 5.  Once we finish
some of these items and get them off our plate we could roll new items
onto the plate, theoretically.



That's definitely true going forward, but what I was saying is that 
the number of items under consideration is now down to 4, with SWD 
moving to the Apps group. I was proposing that the whole 
introspection endpoint and general AS-PR connection could be this 
group's fifth starting document.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Justin Richer]

I think we might be crossing wires about input to the token 
introspection endpoint vs. output from it.


In OpenID Connect, you send a JWT in, and get back a JSON object that 
represents the Claims bit of the JWT.


In our implementation (and I think both Ping and AOL's), you send in an 
arbitrary token (with no proscribed format) and get back a JSON object 
with different pieces in it. Ours included a list of scopes and an 
expiration timestamp, others did different things, like audience and 
issuer, as part of the return.


The point I was trying to make is that the information returned from the 
AS-PR interface isn't necessarily embedded inside of the token used to 
call that interface. In OpenID Connect, it is, and the CheckID endpoint 
just unwraps the JWT for you. In the larger case, what's really going on 
is that the PR presents a token that it's not sure what it's good for 
and gets back something that answers that question. Since a JWT Claims 
section can be an arbitrary JSON object (for all intents and purposes), 
you could use a JWT as the output of the introspection endpoint as well.


 -- Justin

On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote:

Hi Justin,

I refered to the data format used at the AS-PR interface. According to 
your description, you use JSON objects there. What data does such an 
object contain? Is this any different from a JSON Web Token (leaving 
aside digital signatures and encryption)?


regards,
Torsten.

Am 18.04.2012 22:01, schrieb Justin Richer:
Not all implementations in the field that do this are using JWTs as 
the tokens. Ours in particular used a random blob with no structured 
information in it. The endpoint returned a JSON object.


 -- Justin

On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:

Hi all,

is there enough experience in the field with such an interface to 
standardize it?


I would expect such an endpoint to return the same payload, which is 
carried in a JSON Web Token. So once we designed the JSON Web Tokens 
content, designing the AS-PR interface could be the next logical 
step (after the next re-charting).


regards,
Torsten.

Am 16.04.2012 21:04, schrieb Justin Richer:



OK, but with SWD and discovery off the table, can this now be
considered to be within that manageable number instead?
We wanted to keep the # of WG items to approximately 5.  Once we 
finish
some of these items and get them off our plate we could roll new 
items

onto the plate, theoretically.



That's definitely true going forward, but what I was saying is that 
the number of items under consideration is now down to 4, with SWD 
moving to the Apps group. I was proposing that the whole 
introspection endpoint and general AS-PR connection could be this 
group's fifth starting document.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IIW and OAuth

[Justin Richer]

As I understand it, the tag of "Yukon Day" is a suggestion and doesn't 
change the unconference format, and IIW attendees are free to ignore the 
theme, just like NSTIC day last time around.


 -- Justin

On 04/23/2012 10:22 AM, John Bradley wrote:

I was talking to Phil last week and Thursday is open IIW time like Tuesday - 
Wednesday.  I had thought it was a Yukon day as well, but that is apparently 
not happening.

I think there is also a OASIS trust elevation TC thing Marry is trying to do on 
Thursday as well at IIW.

John B.
On 2012-04-22, at 5:50 PM, Eve Maler wrote:


I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. Some 
UMAnitarians have suggested proposing an IIW session to collect OAuth AS/RS 
separation use cases. I'm happy to champion that on the Tuesday if there's 
interest.

Also, we're planning to have an UMA "open meeting" during a couple of Thursday afternoon 
blocks, if any folks on this list would like to join in. (Thursday is "Yukon day", which 
is roughly the personal data ecosystem day. I can't recall how it got this moniker.)

Eve

On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys,

I was wondering how many of you will be at the upcoming IIW in Mountain View 
(or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 
3rd).

I thought it might be good to useful to get together on the Friday after the 
IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them 
out of the door.
(And thanks to those who have already read them.)

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Eve Maler  http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2 flow diagrams

[Justin Richer]

We've moved our git repository away from one that was tied to my 
personal account (jricher) and into a more appropriate "GitHub 
Organization" one. This means that the URLs pointing to the diagrams 
mentioned below have changed. The correct URL is now:


https://raw.github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/master/docs/OAuth2.0_Diagrams.pdf

This will point to the latest version. There are also some OpenID 
Connect diagrams (using the same style) in that same directory if 
anyone's interested.


 -- Justin

On 02/07/2012 09:46 AM, Anganes, Amanda L wrote:


Hello again,

Based on some feedback I have received I have updated my diagrams. 
Changes are listed below, and the link 
(https://github.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf?raw=true) 
will always point to the latest version.


* Changed the title of the diagrams to "OAuth 2.0 Authorization" (from 
"OAuth 2.0 Authentication", which was incorrect).


* Removed refresh_token from the Access Token response on the Client 
Credentials flow.


Ref: http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4.3 
says "A refresh token SHOULD NOT be included."


* Changed "Consumer" to "Client" to better match the 2.0 terminology.

/Amanda Anganes/

Info Sys Engineer, G061

The MITRE Corporation

782-271-3103

aanga...@mitre.org

*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On 
Behalf Of *Anganes, Amanda L

*Sent:* Friday, February 03, 2012 9:24 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] OAuth 2 flow diagrams

Hello,

I've developed a set of flow diagrams for the OAuth 2.0 spec, with 
separate diagrams for the Access Code, Implicit Grant, Resource Owner 
Password Credentials, and the Client Credentials flows. These were 
inspired by the diagrams for 1.0 and 1.0a that Idan Gazit posted in 
http://www.ietf.org/mail-archive/web/oauth/current/msg00696.html, 
which Justin Richer pointed me to when I first started trying to read 
and understand the OAuth2.0 spec. I find these types of diagrams to be 
incredibly useful, so I updated them again to (hopefully) reflect the 
2.0 spec.


I'd appreciate any comments/corrections. If anyone finds the diagrams 
to be useful, please feel free to rehost or reference them.


https://github.com/jricher/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf?raw=true

Thanks,

/Amanda Anganes/

Info Sys Engineer, G061

The MITRE Corporation

782-271-3103

aanga...@mitre.org <mailto:aanga...@mitre.org>



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know

[Justin Richer]

It's important to remember that these identifiers need to be handled, 
seen, and remembered by people. Especially in the long-tail case (which 
is to say, IdPs who aren't big enough to get a log in button), users 
will need to enter a piece of text into a website to tell the website 
who they are. There's the longstanding usability issue of how users 
self-identify. We have taught people over the last 30 years or so that a 
format of "user@domain" represents a person. SMTP, XMPP, SIP, and other 
protocols have used this format successfully. OpenID made the mistake of 
trying to teach people that "http://domain/user";  could also stand for 
them, but people just don't think of themselves in terms of HTTP URLs. 
Webfinger came about to address this, and SWD adopted the same pattern. 
Account Chooser is a great UI for public, internet-facing websites, but 
it's far from universally applicable.


Whether it's good privacy practice or not, the natural pattern for 
people to log into a website is to type something that looks like an 
email address. Also note that while in many peoples' cases, the 
acct:user@domain will match their mailto:user@domain address, but that's 
not necessarily true universally. This adds flexibility for allowing a 
domain-style identifier to use the same discovery process as a 
user@domain-style identifier and privacy-conscious users can use the former.


 -- Justin

On 05/10/2012 10:58 AM, John Bradley wrote:

openID Connect dosen't require a user portion of the identifier to be 
discovered and supports a opaque or pseudonymous user_id.
email is an optional attribute that can be returned by user consent.

OpenID 2.0 actively discouraged using email addresses for privacy reasons.  
Teaching people to enter there email addresses into unknown sites was seen as a 
bad thing by many.

WF was started partially as an alternative discovery mechanism for openID to 
allow people to enter email addresses to discover there IdP, given a belief 
that users could only be asked to enter email and
NASCAR UI was not scalable.

openID is attempting to separately address the NASCAR problem with it's Account 
Chooser project to allow the user to configure and control their selection of 
IdP without entering info directly into the RP.

For WF/SWD the decision is to enforce discovery by host only or support a user 
component so that a email or other service provider could allow per user choice.

I do happen to personally agree that teaching users to give up there email to 
random websites is not a good idea, however not allowing a user component in 
discovery won't stop RP from asking and removes otherwise useful functionality 
and choice fro the user.

John B.

On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote:


Hmmm, I see your point but I think that from a privacy PoV revealing the 
username to the RP is not good practice, especially not prior to trust being 
established between RP and IdP. If the IdP wants to send the assertion in the 
authentication statement that is another matter. But you don't want rogue RPs 
harvesting user names. So instead i have assumed that the domain could be more 
specific if needed, i.e. for 99% of the cases example.com would suffice but for 
the corner cases I imagine using idp1.example.com and idp2.example.com. But I 
understand that in an oauth scenario that may be less pretty.

Klaas

Sent from my iPad

On 9 mei 2012, at 21:31, "John Bradley"  wrote:


The lookup is based on the identifier provided by the user.  It can have a user 
portion in the format of a URI https://j...@example.com , 
https://example.com/john or anything else where you can extract the domain.

The user portion is necessary to allow for per user IdP delegation.   Otherwise 
only one IdP per host could be supported.

John B.


On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote:


Hi John,

does the "identifier" contain of a domain part AND a username part or only the 
domain part?
That's the crucial question here.

Ciao
Hannes

On May 9, 2012, at 9:20 PM, John Bradley wrote:


For openID Connect we are using the identifier to discover the AS.   We refer 
to that as an issuer,  and perform a second discovery step to get the 
configuration (Auth endpoint, token endpoint, user_info endpoint and other 
config) for that issuer.

SWD/WF may be used for other things by other protocols, but our use is quite 
simple.

I think that is probably the same thing for SASL,  but others may think 
differently.

John B.


On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote:


Hi guys,

at the last IIW we had a discussion about SASL-OAuth and what the SASL server 
needs to know for discovery.
The discovery discussions around WebFinger go in the same directions.

So, I have been wondering whether we have made an informed decision about how 
the discovery procedure is actually supposed to look like.

In my view, the relying party (the client) only needs to know who the identity 
provider (the AS/RS) is.

Any other

Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

[Justin Richer]

This kind of fully automated approach isn't solved yet. OAuth isn't 
quite as simple as HTTP Basic and its kin, where the user agent can 
collect everything it needs directly and just push it back to the 
protected URL. In order for this to truly work, you need to have not 
just a pointer to the issuer, but a full dynamic registration and 
service discovery stack that the client knows about. For starters, the 
Client needs to know the Authorization Endpoint and Token Endpoint for 
the service, as well as which flows it supports. You'd probably want to 
know what kinds of token are supported, too. The authorization server 
needs to issue a Client ID and (probably) Client Secret to the Client to 
allow it to request tokens at all. Defining those is out of scope for 
the core specs, but there's some new work that's getting started around 
Host Meta (for discovery) and a dynamic client registration spec that 
will address some of the biggest parts of this.


 -- Justin

On 05/15/2012 08:12 AM, Sergey Shishkin wrote:
While designing a hypermedia-driven API I'm evaluating possibilities 
to use OAuth Bearer tokens for claims-based authorization. Currently I 
struggle with how to communicate to the API client the way to obtain 
the token. In a hypermedia-driven manner I don't want the API client 
to get this information out of band, but rather let the client "just 
follow the links".


The Bearer draft 
[http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-3] 
advises to send a 401 response with a WWW-Authenticate challenge 
specifying optional realm and scope. The problem here: neither realm 
nor scope identify the token issuer.


The OAuth 2.0 draft 
[http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1] 
suggests to redirect the resource owner to the token issuer, IIRC. I 
like this way from the hypermedia perspective, but still have mixed 
feelings about missed 401 and WWW-Authenticate challenge.


Did I missed some part of draft covering my scenario? Are there any 
known grassroots implementations doing just that on the internet? Any 
opinion on the subject is very much appreciated.


Thanks in advance,
Sergey


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MAC Token draft

[Justin Richer]

I also think it's worthwhile. OAuth2 doesn't provide a way to do a 
signed-http-request in the way that OAuth1 does. I would definitely like 
to see this draft make its way to completion, but I don't have the 
crypto expertise to pick up editing it myself.


 -- Justin

On 05/16/2012 11:51 AM, William Mills wrote:
I think there is a need for a signed token style OAuth 2 scheme, and 
MAC fills this niche, although holder-of-key (as yet un-drafted) would 
also do this nicely.  Is MAC going to get picked up and driven to 
completion?


Do others feel this token style (and security properties) are needed?  
Or am I alone in this?


-bill


*From:* Eran Hammer 
*To:* "oauth@ietf.org WG (oauth@ietf.org)" 
*Sent:* Tuesday, May 15, 2012 6:41 PM
*Subject:* [OAUTH-WG] MAC Token draft

I am stepping down from my role as editor of the MAC token
specification. I do not intend to participate in this work moving
forward. I will forward my notes to the next editor if requested.
EH

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

[Justin Richer]

First, I have to give proper credit to my colleague Amanda Anganes for 
making those flow diagrams (which I agree are pretty awesome -- when 
coding I refer to them as often as the spec text itself, personally).


Yes, you have it right, in this case the RS is the client of the 
identity API from the AS, which looking back at your original question 
isn't quite what you were asking, so I apologize for the confusion 
there. Just so I have this straight:


You have a client, C, making an OAuth protected call to service RS using 
a token that's been generated by one of a set of trusted authorization 
servers, AS1-AS12. So RS needs to figure out:


1) Is the token any good?
2) Is the token issued by someone I know?
3) What's the user information tied to the token? (name and stuff)

If that's the case, there are a few ways to handle this, but one of the 
simplest is to make use of the bearer token principle and chain the 
service calls around a bit. Especially if your AS's all use a structured 
token format, like JWT, that can point to the issuer of the token (and 
therefore which AS spit it out in the first place).


So in concrete terms:

Client C calls AS1 and gets access token AT. AT is a JWT that has in its 
claims section {iss: AS1}, among others. C passes AT to RS to make its 
call. RS can inspect the JWT and discover the token was sent from AS1 
(by the issuer field). RS knows that AS1 is in its list of trusted AS's. 
RS validates the signature on AT against the key from AS1 (which can be 
done using JWK). Now that the token is good, the RS can start to fulfill 
the client's request. The RS could also call what's being termed an 
"introspection endpoint" at AS1 to help it figure out what the token is 
good for (scopes, permissions, timeouts, etc) in fulfilling the client's 
request. But say RS needs user information like a name and email address 
and all that. Well, if the AS's are all doing OpenID Connect, which 
would still give you a valid access token, then the AS's will all *also* 
have a User Info Endpoint defined. The RS can send the AT to the 
UserInfo Endpoint to get the user's information from it in a simple JSON 
schema. You can alternatively use SCIM or PoCo formatted endpoints to 
accomplish much of the same stuff, all protected over OAuth.


There are some more complicated methods, with the RS trading in the AT 
for its own subscoped AT for instance, but this is a basic and fairly 
functional usage scenario. Do you think this covers what you'd want to 
do with it? It's still about 80% vanilla OAuth2.


 -- Justin

On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote:

Maybe I'm getting confused over the terminology.  Connect speaks of a client 
talking to a CheckID endpoint or UserInfo endpoint.  Is the RS acting as the 
client in this case?

I'm actually looking at your famous PDF diagrams Justin, and it looks like the 
client is in all cases the same client.  E.g. the client that asks for the 
access token is the same client performs the UserInfo request or CheckID 
request.  In my mind, I want the client to get the access-token and present it 
to the RS, and then I want the RS to perform the UserInfo request or CheckID 
request.

So if you're telling me that the RS is acting as the client, and the RS can 
perform the UserInfo request or CheckID request, then I get it.  But it wasn't 
obvious from the spec.


Tx!
adam




-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Friday, June 01, 2012 10:00 AM
To: Manger, James H
Cc: Lewis Adam-CAL022; oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

More specifically, OpenID Connect with the addition of reusing the access_token 
provided by the AS to get at other API services. This capability is explicitly 
encouraged in Connect since it directly re-uses the OAuth2 infrastructure and 
tokens to do the identity protocol.

  -- Justin

On Jun 1, 2012, at 10:33 AM, Manger, James H wrote:


Adam,

You are describing OpenID Connect.

--
James Manger

- Reply message -
From: "Lewis Adam-CAL022"
Date: Sat, Jun 2, 2012 12:00 am
Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited)
To: "oauth@ietf.org"

Hi all,

I've asked about the lack of standardization of the AS-RS interface in the past, but I 
have a new twist on my question.  What is the viability of performing user 
"authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's 
in different domains (assuming that the RS and AS is of the same implementation)?

RS (domain-1)

AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n

Let me explain a bit further.  I have a RS in domain-1 which exposes an API, 
which is accessed by a native client, with users from (for example) 12 
different domains.  (Note: both the RS and native clients are of the same 
vendor implementation).  Each of the 12 user domains has an AS, of the same 
implementation as the RS in domain-1.  I'm thinking that n

Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

[Justin Richer]

Right, if you've got a fully signed JWT (using JWS) then you don't need 
much in introspection because you *can* pack everything in the token. 
But introspection gives you the option to put some bits in the token and 
leave some other bits as a callable API, which is nice.


If you don't use a JWT, I would at least suggest using a 
slightly-structured token so that your RS can key which AS the token 
came from. Otherwise it's going to have to check all of them, which is a 
huge waste of bandwidth and time. (and very leaky security!!)


We've got a JWT-spewing implementation built on top of Spring Security 
OAuth in our OpenID Connect server, if you're up on Java and Spring and 
Spring Security (like a lot of our enterprise is) then it might be up 
your alley.


https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server

This adds a set of token services to the existing Spring Security OAuth 
with some different capabilities, and one of these is a full Java JWT 
library.


 -- Justin

On 06/01/2012 04:17 PM, Lewis Adam-CAL022 wrote:

Hi Justin,

Yes ... this is making me feel a lot better about things.  So just a few more 
points of clarification:

1. if the OAuth access-token is a JWT, then it seems there is nothing for me to 
introspect ... because all the info is in the JWT and the RS can validate the 
signature itself.
2. what OAuth AS implementations today actually give me a structure JWT 
access-token?  Most that I am aware of give me an unstructured token.
3. even if I could get a JWT (which I would definitely be interested in 
exploring) the unstructured token still gives my major bandwidth advantage 
(again, because of my edge cases).


Tx!
adam


-----Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Friday, June 01, 2012 3:00 PM
To: Lewis Adam-CAL022
Cc: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

First, I have to give proper credit to my colleague Amanda Anganes for
making those flow diagrams (which I agree are pretty awesome -- when
coding I refer to them as often as the spec text itself, personally).

Yes, you have it right, in this case the RS is the client of the
identity API from the AS, which looking back at your original question
isn't quite what you were asking, so I apologize for the confusion
there. Just so I have this straight:

You have a client, C, making an OAuth protected call to service RS using
a token that's been generated by one of a set of trusted authorization
servers, AS1-AS12. So RS needs to figure out:

1) Is the token any good?
2) Is the token issued by someone I know?
3) What's the user information tied to the token? (name and stuff)

If that's the case, there are a few ways to handle this, but one of the
simplest is to make use of the bearer token principle and chain the
service calls around a bit. Especially if your AS's all use a structured
token format, like JWT, that can point to the issuer of the token (and
therefore which AS spit it out in the first place).

So in concrete terms:

Client C calls AS1 and gets access token AT. AT is a JWT that has in its
claims section {iss: AS1}, among others. C passes AT to RS to make its
call. RS can inspect the JWT and discover the token was sent from AS1
(by the issuer field). RS knows that AS1 is in its list of trusted AS's.
RS validates the signature on AT against the key from AS1 (which can be
done using JWK). Now that the token is good, the RS can start to fulfill
the client's request. The RS could also call what's being termed an
"introspection endpoint" at AS1 to help it figure out what the token is
good for (scopes, permissions, timeouts, etc) in fulfilling the client's
request. But say RS needs user information like a name and email address
and all that. Well, if the AS's are all doing OpenID Connect, which
would still give you a valid access token, then the AS's will all *also*
have a User Info Endpoint defined. The RS can send the AT to the
UserInfo Endpoint to get the user's information from it in a simple JSON
schema. You can alternatively use SCIM or PoCo formatted endpoints to
accomplish much of the same stuff, all protected over OAuth.

There are some more complicated methods, with the RS trading in the AT
for its own subscoped AT for instance, but this is a basic and fairly
functional usage scenario. Do you think this covers what you'd want to
do with it? It's still about 80% vanilla OAuth2.

   -- Justin

On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote:

Maybe I'm getting confused over the terminology.  Connect speaks of a client 
talking to a CheckID endpoint or UserInfo endpoint.  Is the RS acting as the 
client in this case?

I'm actually looking at your famous PDF diagrams Justin, and it looks like the 
client is in all cases the same client.  E.g. the client that asks for the 
access token is t

Re: [OAUTH-WG] ABNF elements for suggested WG review

[Justin Richer]

Agreed with Eran, there shouldn't be restrictions on most of these 
fields. Though it should address Julian's request of how do you define 
encoding on these fields explicitly.


 -- Justin

On 06/04/2012 03:16 PM, Eran Hammer wrote:


The ABNF must reflect the existing draft, not invent new restrictions. 
The only field we had consensus for applying new restrictions on is 
error (and the related ones from bearer). That's it. Please have the 
proposed ABNF reflect the unrestricted nature of all values not 
explicitly defined otherwise.


EH

*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On 
Behalf Of *Mike Jones

*Sent:* Saturday, June 02, 2012 1:10 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] ABNF elements for suggested WG review

Dear working group,

It turns out that writing an ABNF for the Core spec pointed out that 
the syntax of a number of the OAuth protocol elements had not been 
previously defined.  (Thanks, Sean, for having us do this!)  I took a 
stab at specifying appropriate ABNF values for each of the protocol 
elements, but I would request that the working group actively review 
the choices in my proposed draft.


For instance, I chose to use the same syntax definitions for username 
and password and client_id and client_secret as HTTP Basic used for 
userid and password.  Other choices were possible, such as perhaps 
limiting client_id and possibly username values to use "unreserved" 
characters, rather than allowing all characters other than ":" (as 
HTTP Basic did with userid).


Please particularly review the syntax definitions for these elements, 
as I had to make choices that went beyond the current specs to provide 
unambiguous syntax definitions:


   client_id

   client_secret

   state

   code

   access_token

   username

   password

   refresh_token

The full proposed ABNF section follows.

-- Mike

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax

   This section provides Augmented Backus-Naur Form (ABNF) syntax

   descriptions for the elements defined in this specification using the

   notation of [RFC5234].  Elements are presented in the order first

   defined.

   Some of the definitions that follow use the "unreserved" and "URI"

   definitions from [RFC3986], which are:

   unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

   URI= scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   Some of the definitions that follow use the "b64token" syntax below,

   which matches the "b64token" syntax defined by HTTP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:

   b64token   = 1*( ALPHA / DIGIT /

"-" / "." / "_" / "~" / "+" / "/" ) *"="

A.1.  "client_id" Syntax

   The "client_id" element is defined in Section 2.3.1:

   client-id = *

   (This matches the "userid" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

A.2.  "client_secret" Syntax

   The "client_secret" element is defined in Section 2.3.1:

   client-secret = *TEXT

   (This matches the "password" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

A.3.  "response_type" Syntax

   The "response_type" element is defined in Section 3.1.1 and

   Section 8.4:

   response-type = response-name *( SP response-name )

   response-name = 1*response-char

   response-char = "_" / DIGIT / ALPHA

A.4.  "scope" Syntax

   The "scope" element is defined in Section 3.3:

   scope   = scope-token *( SP scope-token )

   scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

A.5.  "state" Syntax

   The "state" element is defined in Section 4.1.1, Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:

   state  = 1*unreserved

A.6.  "redirect_uri" Syntax

   The "redirect_uri" element is defined in Section 4.1.1,

   Section 4.1.3, and Section 4.2.1:

   redirect-uri  = URI

A.7.  "error" Syntax

   The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

   error = 1*error-char

   error-char= %x20-21 / %x23-5B / %x5D-7E

A.8.  "error_description" Syntax

   The "error_description" element is defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:

   error-description = 1*error-char

   error-char= %x20-21 / %x23-5B / %x5D-7E

A.9.  "error_uri" Syntax

   The "error_uri" element is defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:

   error-uri = URI

A.10.  "grant_type" Syntax

   The "grant_type" element is defined in Section 4.1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

   grant-type = grant-name / URI

   grant-name = 1*name-char

   name-char  = "-" / "." / "_" / DIGIT / ALPHA

A.11.  "code" Syntax

   The "code" element is defined in Section 4.1.3:

   code   = 1*unres

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

[Justin Richer]

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 though the Access Token is short lived, I would still like to 
revoke it immediately if the user chooses to revoke the Refresh 
Token.  And I would love for the client application to only have to 
make one web service call to accomplish that and not one for the 
Refresh Token and another for the Access Token.
Given that we always generate a new Refresh Token value during "Token 
Refresh", we would never have a true parent / child relationship 
between a Refresh Token and Access Token.
Is there a case where it is NOT appropriate to revoke an "associated" 
Access Token when explictly revoking a Refresh Token?  I define 
"associated" as an Access Token generated from a Refresh Token OR 
generated at the same time of the Refresh Token.
I do see the AS challenges in trying to manage multiple 
simultaneous "associated" Access Tokens.  For example let's say a 
client generates multiple Access Tokens at the same time while 
generating new Refresh Token values during each "Token Refresh" 
operation.  However I don't really see the useful of this case.

Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen > wrote:


Hi George, perhaps it depends on the reason for the refresh token
being revoked. If because the user removed their consent then yes
I agree that *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher mailto:gffle...@aol.com>> wrote:


Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back
both an access_token and a refresh_token then I would assume that
the issued access_token is tied in some way to the refresh_token.
If the refresh_token is revoked, then my expectation is that the
simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens
associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token
and access_token, then the new ones should be valid and the old
ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:

Hi Doug, my interpretation is that 'for that refresh token'
means those access tokens issued in exchange for that refresh
token.

Consequently, for the cases you cite below, the access tokens at
the same time as a given refresh token need not be invalidated
when that refresh token is 'processed'

I assume the justification for the rule is that an access token
issued in exchange for a given refresh token may have been
compromised if the refresh token had been. But there is no such
causal relationship between an access token & refresh token
issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:

Hi all,

I was hoping to get some clarity on a statement in section 2.0
of draft-ietf-oauth-revocation-00.

If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens
issued
for that refresh token.

My question is on the statement "access tokens issued for that
refresh token". What does it mean to have an Access Token
"issued" for a Refresh Token?

This specific case is clear to me. I am refreshing an Access
Token where I keep the same Refresh Token that I used to
generate the new Access Token. I see the new Access Token was
issued for that Refresh Token.
However these two cases are a bit muddy to me. Let's say I am
using the "Resource Owner Password Credentials Grant" where the
Access Token Response returns both an Access Token and Refresh
Token. Would the Access Token have been issued for that Refresh
Token? And let's say I am refreshing an Access Token but choose
to create a new Refresh Token and immediately revoke the
original Refresh Token. Would the newly created Access Token
have been issued for the original Refresh Token or the new one
that was created.
If a client would revoke a Refresh Token ... I would like the
Access Tokens in all of the above cases to be automatically
revoked as well. I just want to make sure I understand the
model. Thanks.
Doug Foiles
Intuit

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

[Justin Richer]

Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:


I was asked a question off-list, which I think is worth answering 
on-line.  The question was:  Why the Tab character, rather than 
%-encoding?


Introducing % encoding would break all existing OAuth 2.0 deployments 
using HTTP Basic.  A non-starter...


Tab is legal in HTTP Basic but not in URLs or presently client_ids.  
It's also a character that can be visibly rendered in an acceptable 
manner for debugging.  The other choices were CR and LF, which are 
also legal in HTTP Basic but wouldn't render very nicely. ;-)


Cheers,

-- Mike

*From:*Mike Jones
*Sent:* Friday, June 15, 2012 9:30 AM
*To:* 'Eran Hammer'
*Cc:* George Fletcher; oauth@ietf.org
*Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


I agree with Eran that I prefer that this not be underspecified and 
that an encoding for just colon for just Basic will suffice.


I'd suggested the encoding s/://g as a strawman.  Are there any 
other encoding proposals?


-- Mike

*From:*Eran Hammer [mailto:e...@hueniverse.com] 


*Sent:* Friday, June 15, 2012 9:26 AM
*To:* Mike Jones
*Cc:* George Fletcher; oauth@ietf.org 
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


We should not leave this under specified. Picking an encoding for just 
Basic and just colon is simple enough.


EH

On Jun 15, 2012, at 19:17, "Mike Jones" > wrote:


Based on use cases I'm seeing, believe it's important to allow the
use of URIs as client_id values (which means allowing ":" in the
client_id string).  I'm OK with us either specifying a specific
encoding when using them in Basic or simply saying that "When
client_ids are used with HTTP Basic that contain characters such
as ":" not allowed in HTTP Basic usernames, then the participants
will need to agree upon a method of encoding the client_id for use
with HTTP Basic.

-- Mike

*From:*oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org]
 *On Behalf Of *George
Fletcher
*Sent:* Friday, June 15, 2012 8:48 AM
*To:* oauth@ietf.org 
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re:
Discussion needed on username and password ABNF definitions

+1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit
problem with URI in client_id is HTTP username field being :
terminated.
As such it does not have to be a hash per-se, just an encoding
that removes ":" and other reserved characters from the on-wire
form *when sent via HTTP*.

AYJ

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

So it's been pointed out to me that percent encoding like this would 
break any clients that already have % in their client_id who are using 
the Basic auth. My question to the group is: how many of these are out 
there, really? Do we really have to worry about them? Right now, those 
are just hyptothetical, whereas clients with a : are real.


Considering there already are (at the moment, technically noncompliant) 
clients using : who aren't using basic that we're definitely trying to 
support (otherwise this issue wouldn't be coming up), I would argue in 
favor of the known-existence side as opposed to the potential-existence 
side. Which is to say, use percent encoding (which is established and 
referenceable from another spec) and call it a day.


What *really* bothers me about the strawman proposal is that it's making 
up a new, arbitrary encoding mechanism for one corner case. This is such 
a tiny and oddly specific-to-OAuth2 thing that my gut instinct tells me 
this is going to be either:

  1) ignored
  2) implemented wrong
  3) coupled with some other encoding mechanism for people who want to 
do other things like internationalization


 -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:

Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:


I was asked a question off-list, which I think is worth answering 
on-line.  The question was:  Why the Tab character, rather than 
%-encoding?


Introducing % encoding would break all existing OAuth 2.0 deployments 
using HTTP Basic.  A non-starter...


Tab is legal in HTTP Basic but not in URLs or presently client_ids.  
It's also a character that can be visibly rendered in an acceptable 
manner for debugging.  The other choices were CR and LF, which are 
also legal in HTTP Basic but wouldn't render very nicely. ;-)


Cheers,

-- Mike

*From:*Mike Jones
*Sent:* Friday, June 15, 2012 9:30 AM
*To:* 'Eran Hammer'
*Cc:* George Fletcher; oauth@ietf.org
*Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


I agree with Eran that I prefer that this not be underspecified and 
that an encoding for just colon for just Basic will suffice.


I'd suggested the encoding s/://g as a strawman.  Are there any 
other encoding proposals?


-- Mike

*From:*Eran Hammer [mailto:e...@hueniverse.com] 
<mailto:[mailto:e...@hueniverse.com]>

*Sent:* Friday, June 15, 2012 9:26 AM
*To:* Mike Jones
*Cc:* George Fletcher; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


We should not leave this under specified. Picking an encoding for 
just Basic and just colon is simple enough.


EH

On Jun 15, 2012, at 19:17, "Mike Jones" <mailto:michael.jo...@microsoft.com>> wrote:


Based on use cases I'm seeing, believe it's important to allow
the use of URIs as client_id values (which means allowing ":" in
the client_id string).  I'm OK with us either specifying a
specific encoding when using them in Basic or simply saying that
"When client_ids are used with HTTP Basic that contain characters
such as ":" not allowed in HTTP Basic usernames, then the
participants will need to agree upon a method of encoding the
client_id for use with HTTP Basic.

-- Mike

*From:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org]
<mailto:[mailto:oauth-boun...@ietf.org]> *On Behalf Of *George
Fletcher
*Sent:* Friday, June 15, 2012 8:48 AM
*To:* oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re:
Discussion needed on username and password ABNF definitions

+1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit
problem with URI in client_id

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

[Justin Richer]

Just to clarify, I was actually referring to the self-issued OpenID 
Connect clients that Nat and others have been working on that sparked 
this discussion of the utility of colon, not ones that we have here 
locally in our implementations.


 -- Justin

On 06/15/2012 02:58 PM, Mike Jones wrote:


Justin, it's a useful data point that you already have clients with 
colon (":") in client_id values (that work because you aren't using 
HTTP Basic).  Thanks for letting us know that.


For the record, I'd be fine if the working group decided that 
%-encoding of client_id values when used with HTTP Basic was the right 
thing to do.  The Tab strawman was intended to break as few 
implementations as possible, but I fully recognize that the set of 
implementations broken by using % for %-encoding may well be the empty 
set.


Other's thoughts?

Cheers,

        -- Mike

*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Friday, June 15, 2012 11:53 AM
*To:* Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


So it's been pointed out to me that percent encoding like this would 
break any clients that already have % in their client_id who are using 
the Basic auth. My question to the group is: how many of these are out 
there, really? Do we really have to worry about them? Right now, those 
are just hyptothetical, whereas clients with a : are real.


Considering there already are (at the moment, technically 
noncompliant) clients using : who aren't using basic that we're 
definitely trying to support (otherwise this issue wouldn't be coming 
up), I would argue in favor of the known-existence side as opposed to 
the potential-existence side. Which is to say, use percent encoding 
(which is established and referenceable from another spec) and call it 
a day.


What *really* bothers me about the strawman proposal is that it's 
making up a new, arbitrary encoding mechanism for one corner case. 
This is such a tiny and oddly specific-to-OAuth2 thing that my gut 
instinct tells me this is going to be either:

  1) ignored
  2) implemented wrong
  3) coupled with some other encoding mechanism for people who want to 
do other things like internationalization


 -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:

Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:

I was asked a question off-list, which I think is worth answering 
on-line.  The question was:  Why the Tab character, rather than 
%-encoding?


Introducing % encoding would break all existing OAuth 2.0 deployments 
using HTTP Basic.  A non-starter...


Tab is legal in HTTP Basic but not in URLs or presently client_ids.  
It's also a character that can be visibly rendered in an acceptable 
manner for debugging.  The other choices were CR and LF, which are 
also legal in HTTP Basic but wouldn't render very nicely. ;-)


Cheers,

-- Mike

*From:*Mike Jones
*Sent:* Friday, June 15, 2012 9:30 AM
*To:* 'Eran Hammer'
*Cc:* George Fletcher; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


I agree with Eran that I prefer that this not be underspecified and 
that an encoding for just colon for just Basic will suffice.


I'd suggested the encoding s/://g as a strawman.  Are there any 
other encoding proposals?


-- Mike

*From:*Eran Hammer [mailto:e...@hueniverse.com] 
<mailto:[mailto:e...@hueniverse.com]>

*Sent:* Friday, June 15, 2012 9:26 AM
*To:* Mike Jones
*Cc:* George Fletcher; oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
Discussion needed on username and password ABNF definitions


We should not leave this under specified. Picking an encoding for just 
Basic and just colon is simple enough.


EH

On Jun 15, 2012, at 19:17, "Mike Jones" <mailto:michael.jo...@microsoft.com>> wrote:


Based on use cases I'm seeing, believe it's important to allow the
use of URIs as client_id values (which means allowing ":" in the
client_id string).  I'm OK with us either specifying a specific
encoding when using them in Basic or simply saying that "When
client_ids are used with HTTP Basic that contain characters such
as ":" not allowed in HTTP Basic usernames, then the participants
will need to agree upon a method of encoding the client_id for use
with HTTP Basic.

Re: [OAUTH-WG] Report an authentication issue

[Justin Richer]

3)If I wanted to use OAuth, the client would send an authorization 
request to the server's AS, which would authenticate the user of the 
client, and ultimately result in the client possessing an 
access-token.  My thinking is that this access token (let's assume 
it's a JWT) would contain the user's identity, a statement of what 
type of primary authentication was used (auth context), an expiration, 
and an audience claim.  This sounds a lot like authentication to me, 
and it's where I get confused.  Is it just because OAuth does not 
explicitly define this?  Is there a threat in using OAuth as I describe?




You've hit on it here -- you're using OAuth *plus* a few other bits to 
accomplish this. Using a JWT lets you do things like signed tokens and 
audience restriction so that clients won't just take *any* token.


4)If I wanted to use Connect, well I'm not even sure how the id_token 
as defined by Connect helps this use case.  The id_token seems to make 
sense when the client is a confidential web server, but it's not clear 
what an iPhone app would do with the id_token ... it's the server in 
the backend that needs to authenticate the user, the iPhone app is 
just an interface to talk to the server.  And it seems as I learn more 
about connect that the id_token is not meant to be sent from the 
iPhone app to the server, just the access token.  So it's really not 
clear how Connect helps solve authentication for an iPhone client app 
talking to a video server.  If I'm sending access-tokens, it's just 
OAuth again.




Connect adds a few things on top of OAuth to make authentication 
possible, and one of these is the id_token. But what you're really after 
in your scenario isn't authentication at the RS per se -- it's 
authorization for accessing it.


 -- Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Report an authentication issue

[Justin Richer]

It's all about how you can swipe a token and inject it into another 
application. It's easier to trap and inject a token in the implicit flow 
because it's exposed to the user agent and there's no client secret tied 
to the token's issuance. To get the same trick to work with the code 
flow on server-based confidential clients, you'd need to inject your 
rogue token into the client's configuration or state. With the implicit 
flow and on devices, it's a bit easier just because the parts of the 
system that need access to the token are more accessible.


 -- Justin

On 06/29/2012 12:53 PM, Antonio Sanso wrote:

Hi John

On Jun 29, 2012, at 1:43 AM, John Bradley wrote:


Authenticating to the client is NOT safe with all of the flows

you are perfectly right here. At the begin of this discussion and reading your blog post 
I was under the impression that this "attack" was tight to the use of the 
implicit grant flaw.
But this is not actually the case as I could reproduce the same scenario 
against a client using the Authorization Code flaw.

Regards

Antonio

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

[Justin Richer]

I'm generally OK with the change, though it does change One problem I 
have with this is that it can give a false sense of security about the 
information being sent to the token endpoint and how trustworthy it is. 
A client_id is public knowledge, and so someone impersonating a client 
on the Authentication Endpoint could also impersonate it on the Token 
Endpoint just as easily. This is not the attack that's being addressed 
here, and the possible phishing vector in the one I'm describing is both 
well known and, I believe, well covered by the existing documents. 
However, I think the new text might confuse people into conflating these 
two.


Basically, I think it needs to be made very clear, especially with this 
change of text, that a client_id on its own should never be taken as 
sufficient for authentication of the client. The context of the user's 
decision, among other things, is as important as a client secret.


 -- Justin

On 07/02/2012 11:17 AM, Mike Jones wrote:


I believe we should adopt this revised text.

-- Mike

*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On 
Behalf Of *John Bradley

*Sent:* Sunday, July 01, 2012 2:22 PM
*To:* oauth@ietf.org WG
*Subject:* [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

Sec 4.1.2 states:

The authorization code is bound to the client identifier and redirection URI.

The security concern Sec 10.5 states

If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was
issued to the same client.
  
Sec 3.2.1

A public client that was not issued a client password MAY use the
"client_id" request parameter to identify itself when sending
requests to the token endpoint (e.g. for the purpose of providing
end-user context, client usage statistics).
  
Nothing in the current spec requires that a Public client send it's client_id or redirect_uri to the token endpoint.

The client _id is only sent if it is a confidential client capable of 
authenticating itself.
The redirect_uri is only sent if the 'redirect_uri' parameter was included in 
the authorization request.
If the client has one registered redirect_uri it would not be sent to the 
authorization or token endpoint.
  
This leaves us with public clients using code flow that cannot determine if a token was granted to them or some other public client.
  
  
I propose changing Sec 3.2.1 to read:
  
A public client that was not issued a client password MUST use the

"client_id" request parameter to identify itself when sending
requests to the token endpoint. This allows the authorization server
to ensure that the code was issued to the same client.
Sending "client_id" prevents the client from
inadvertently accepting a code intended for a client with a different
"client_id".

Also change Sec 4.1.3 from:
o  authenticate the client if client authentication is included and
   ensure the authorization code was issued to the authenticated
   client,

To:
o  authenticate the client if client authentication is included,
o  ensure the authorization code was issued to the authenticated
confidential client or to the public client identified by the
   'client_id',
  
  
  


The Original text implies that it is a good idea to send it, but is unclear on 
what security it provides.

It is a small change that should not brake existing implementations, but will 
increase security for public clients using the code flow.

Regards
John B.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

[Justin Richer]

Implicit grant makes perfect sense when the user agent and client are 
collapsed into a single entity. In other words, if your client is inside 
the user agent then doing a code flow doesn't actually buy you any extra 
security. This is the driving design decision behind having it in there, 
and from my perspective that's clear from the current text.


In a similar manner, the client credentials flow came about from 
collapsing the client with the resource owner, effectively putting the 
resource owner inside the client. In this case the authorization step 
doesn't make any sense and doing a code flow doesn't buy you any greater 
security, either.


 -- Justin

On 07/09/2012 01:31 PM, Dick Hardt wrote:

Hi Mike

Reading over the spec, I think some more color in 4.2 on the risks of 
the Implicit Grant and where it makes sense and where it does not is 
in order.

Also, this should be in Section 9.

Thoughts?

-- Dick

On Jul 9, 2012, at 12:08 AM, Mike Jones wrote:

A preliminary version of OAuth core draft -29 is attached for the 
working group's consideration and discussion on today's call.  I 
believe that this addresses all issues that have been raised, 
including Julian's issues about the ABNF, character sets, and form 
encoding.  Changes are:


  * Added "MUST" to "A public client that was not issued a client
password MUST use theclient_idrequest parameter to identify
itself when sending requests to the token endpoint" and added
text explaining why this must be so.
  * Added that the authorization server MUST "ensure the
authorization code was issued to the authenticated confidential
client or to the public client identified by theclient_idin the
request".
  * Added Security Considerations section "Misuse of Access Token to
Impersonate Resource Owner at Public Client".
  * Deleted ";charset=UTF-8" from examples formerly using
"Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
  * Added the phrase "and a character encoding of UTF-8" when
describing how to send requests using the HTTP request
entity-body, per Julian Reschke's suggestion.
  * Added "The ABNF below is defined in terms of Unicode code points
[UNICODE5]; these characters are typically encoded in UTF-8".
  * For symmetry when using HTTP Basic authentication, also apply
theapplication/x-www-form-urlencodedencoding to the client
password, just as was already done for the client identifier.
  * Reduced multiple blank lines around artwork elements to single
blank lines.
  * Removed Eran Hammer's name from the author list, at his request.
Dick Hardt is now listed as the editor.

Best wishes,
-- Mike
preliminary.html>preliminary.pdf>preliminary.xml>___

OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?

[Justin Richer]

The approval screen is a detail of the UX that the protocol itself 
doesn't address, since there are several instances where an approval 
screen does and does not make sense.


If you're doing a "trust on first use" (TOFU) scenario where the 
resource owner is the same as the end user (remember, they may be 
different entities entirely!), then the approval screen is very 
important. This is the classical OAuth use case, and one of the primary 
novel things that it allows for which other protocols don't. Since most 
of the publicly-facing deployments of OAuth are in this kind of world, 
where you're using the end user to bridge trusted security boundaries 
via OAuth, then you see a lot of this.


If your end user and resource owner are different entities, then the 
person sitting at the browser might not actually have a choice about 
whether to allow access. In this case, it doesn't make any sense to ask 
them because the decision is being made by policy, or by circumstances 
around the request. It does still make sense to do a three-legged OAuth 
in this flow, because you can then bind the context of the user having 
authenticated to the AS in the front channel with the client having 
authenticated to the AS in the back channel. This separating and 
re-binding gives you three legs in an authorization triangle, which is a 
very powerful and secure pattern to follow. We're starting to see things 
like this in the enterprise world around OAuth. Instead of using an 
all-powerful tight binding credential between systems, you've got a 
whitelisted OAuth client. As far as the client knows, it's doing vanilla 
OAuth and the world is all as it should be. This is a very good (and 
somewhat novel) thing for enterprise systems.


But even in the TOFU scenario, it's important to let the user say 
"remember this decision in the future and don't bug me about it". In 
this case, the server remembers the authorization grant decision that 
was previously made by the resource owner and doesn't prompt the user. 
Most OpenID 2.0 setups do this already, and some OAuth setups do as 
well. I think Google does this, I know we're building it in to our 
projects, and I think we'll see more of this functionality going forward.


-- Justin

On 08/03/2012 03:07 AM, Jérôme LELEU wrote:

Hi,

In the OAuth 2.0 spec, I don't see any mention of the "Allow / 
disallow" screen (just after the user is logged in). However, most of 
the OAuth providers I know (Facebook, Google, Twitter...) have such a 
"allow / disallow" screen.


Did I miss something in the spec ?

What are the security concerns about not having such "Allow / 
disallow" screen ?


Thanks.
Best regards,
Jérôme



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?

[Justin Richer]

I agree with the idea that we need to collect and document some best 
practices around the UX of authorization, especially in the case where 
it's the end user making the determination. There have been a few chirps 
about this in the past, but I haven't seen anyone really stand something 
up. The OpenID Foundation has its UI working group which is probably 
good place to start.


 -- Justin

On 08/06/2012 02:55 AM, Jérôme LELEU wrote:

Hi,

Thank you all for your answers.

I read section 1.3.1 : "the authorization server authenticates the 
resource owner and obtains authorization", the "obtains authorization" 
implies the confirmation screen I talked about.
But it's not only about UI. There are some behaviour issues remaining 
: is there a "disallow" button ? where does it point at ? when should 
this screen appear (every time, just the first time and why) ?

This confirmation screen deserves more explanations.

Thanks.
Best regards,
Jérôme



2012/8/3 Doug Tangren mailto:d.tang...@gmail.com>>



On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>> wrote:

Hi Jerome,

you raise a good and important point.

A core part of the OAuth specification is to obtain the
consent of the resource owner. If you look at Section 1.3 of
http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the
different authorization grants that are supported. Except for
the client credential authorization grant every other grant
type requires a protocol exchange to obtain the permission
from the resource owner.

The threats document discusses the importance of the consent
mechanism in more detail.

However, the actual screen (and the importance of the UI
representation) is not standardized. Most standardization
organizations do not standardize the look-and-feel of the
actual permission screen. Having said that I believe it is a
very important aspect of every identity management protocol
and there is research available. Maybe someone should put a
page with a few links together to illustrate the current state
of the art and the best current practice.


This is not an oauth issue but an application UX issue dating back
to oauth 1.

Many service providers offer an "authorize" endpoint that always
asks for authorization (safer for the user but less convenient)
and "authenticate" endpoint that skips authorization if the user
previously authorized the app (more convenient but less safe).



Ciao
Hannes

On Aug 3, 2012, at 12:07 AM, Jérôme LELEU wrote:

> Hi,
>
> In the OAuth 2.0 spec, I don't see any mention of the "Allow
/ disallow" screen (just after the user is logged in).
However, most of the OAuth providers I know (Facebook, Google,
Twitter...) have such a "allow / disallow" screen.
>
> Did I miss something in the spec ?
>
> What are the security concerns about not having such "Allow
/ disallow" screen ?
>
> Thanks.
> Best regards,
> Jérôme
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Justin Richer]

Thanks Justas. The MAC document is currently without an editor within 
the WG, so this is the best place to record the error.


A wider note to the WG: I wouldn't mind taking over editorship of the 
MAC token document so long as I could get a co-editor with enough 
cryptographic expertise to make sure all the magical crypto bits work 
like they should. I've sent an email to the chairs saying as much, as well.


 -- Justin

On 08/05/2012 06:30 AM, Justas Janauskas wrote:

Hello,

Sorry if this is not the right group to send this message; I am new here.

I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.

I made a small program to test correctness of an example and it shows
that it is incorrectly calculated in the document:
https://gist.github.com/3263677

I have also implemented an example from previous draft 00, section 1.2
which shows that request MAC is calculated correctly there:
https://gist.github.com/3263765

Thank you,
Justas Janauskas
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Justin Richer]

I believe that there's value in per-message signing completely apart 
from the channel level encryption. MAC tokens let us do this with a 
per-token secret using a pattern very well established in OAuth1. I'm 
sorry that I wasn't at the Vancouver meeting to voice this opinion, for 
what it's worth.


 -- Justin

On 08/08/2012 12:24 PM, Hannes Tschofenig wrote:

Hi Justas,

thanks for sending your feedback to the list.

There is indeed currently no editor for the document. That is, however, not the 
problem.
The problem, as discussed on the list and also at the last IETF meeting, is 
that we do not yet know what type of security properties we want. The MAC draft 
may or may not provide the type of protection we want.

For that reason we first have to figure out what problem we want to solve 
before we jump into the details of fixing some minor errors.

Ciao
Hannes

On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:


Thanks Justas. The MAC document is currently without an editor within the WG, 
so this is the best place to record the error.

A wider note to the WG: I wouldn't mind taking over editorship of the MAC token 
document so long as I could get a co-editor with enough cryptographic expertise 
to make sure all the magical crypto bits work like they should. I've sent an 
email to the chairs saying as much, as well.

-- Justin

On 08/05/2012 06:30 AM, Justas Janauskas wrote:

Hello,

Sorry if this is not the right group to send this message; I am new here.

I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.

I made a small program to test correctness of an example and it shows
that it is incorrectly calculated in the document:
https://gist.github.com/3263677

I have also implemented an example from previous draft 00, section 1.2
which shows that request MAC is calculated correctly there:
https://gist.github.com/3263765

Thank you,
Justas Janauskas
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Justin Richer]

OK, that's fair. I just don't want process to get in the way of progress.

 -- Justin

On 08/08/2012 05:21 PM, John Bradley wrote:

We did discuss per message signing in Vancouver.

The idea is to get agreement on the threats we are trying to mitigate, then 
decide on the mechanisms.

Per message signing will likely still be one of the mechanisms.

The chair will need to decide if we start fresh and copy the parts of MAC that 
are needed or try and continue the existing MAC draft.

John B.

On 2012-08-08, at 4:59 PM, Justin Richer wrote:


I believe that there's value in per-message signing completely apart from the 
channel level encryption. MAC tokens let us do this with a per-token secret 
using a pattern very well established in OAuth1. I'm sorry that I wasn't at the 
Vancouver meeting to voice this opinion, for what it's worth.

-- Justin

On 08/08/2012 12:24 PM, Hannes Tschofenig wrote:

Hi Justas,

thanks for sending your feedback to the list.

There is indeed currently no editor for the document. That is, however, not the 
problem.
The problem, as discussed on the list and also at the last IETF meeting, is 
that we do not yet know what type of security properties we want. The MAC draft 
may or may not provide the type of protection we want.

For that reason we first have to figure out what problem we want to solve 
before we jump into the details of fixing some minor errors.

Ciao
Hannes

On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:


Thanks Justas. The MAC document is currently without an editor within the WG, 
so this is the best place to record the error.

A wider note to the WG: I wouldn't mind taking over editorship of the MAC token 
document so long as I could get a co-editor with enough cryptographic expertise 
to make sure all the magical crypto bits work like they should. I've sent an 
email to the chairs saying as much, as well.

-- Justin

On 08/05/2012 06:30 AM, Justas Janauskas wrote:

Hello,

Sorry if this is not the right group to send this message; I am new here.

I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.

I made a small program to test correctness of an example and it shows
that it is incorrectly calculated in the document:
https://gist.github.com/3263677

I have also implemented an example from previous draft 00, section 1.2
which shows that request MAC is calculated correctly there:
https://gist.github.com/3263765

Thank you,
Justas Janauskas
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Justin Richer]

Use case #2: signature protection over plain HTTP parameters

MAC gives us message-level signing in a way that doesn't require all the 
parameters to be packed into an extra structure, like JWT/SAML do. TLS 
gives no application-layer verification of integrity of parameters, nor 
does it give you the ability to know who presented those parameters 
(unless you're doing mutual TLS, which nobody does). MAC gives you a 
fairly simple way to protect all parameters on a call to the resource 
server while still keeping all of those parameters in their native HTTP 
forms.



Use case #3: generic signed HTTP fetch (not directly addressed by MAC 
spec as of today)


Sometimes you want to create a URL with one service, fix all of the 
parameters in that URL, and protect those parameters with a signature. 
Then that URL can be passed to an untrusted service who cannot modify 
any portion of it. Nor can they re-use the signature portion to protect 
different parameters. We do this today with a 2-legged OAuth signature 
across a service URL. The "Client" generates the signed URLs and passes 
them to a user agent which actually does the fetch to the service.



 -- Justin

On 08/09/2012 02:43 PM, William Mills wrote:

OK, I'll play and start documenting the use cases.

Use case #1: Secure authentication in plain text connections:

Some applications need a secure form authorization, but do not want or 
need the overhead of encrypted connections.  HTTP cookies and their 
ilk are replayable credentials and do not satisfy this need.   the MAC 
scheme using signed HTTP authorization credentials offer the 
capability to securely authorize a transaction, can offer integrity 
protection on all or part of an HTTP request, and can provide replay 
protection.


-bill


*From:* John Bradley 
*To:* William Mills 
*Cc:* Dick Hardt ; "oauth@ietf.org" 


*Sent:* Thursday, August 9, 2012 11:26 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

In Vancouver the question was asked about the future of the MAC spec 
due to it no linger having a editor.


The Chair and AD indicated a desire to have a document on the 
use-cases we are trying to address before deciding on progressing MAC 
or starting a new document.


Phil Hunt is going to put together a summery of the Vancouver 
discussion and we are going to work on the use-case/problem 
description document ASAP.


People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on 
what it was protecting against.


I think there is general agreement that one or more proof mechanisms 
are required for access tokens.

Security for the token endpoint also cannot be ignored.


John B.

On 2012-08-09, at 1:53 PM, William Mills wrote:

MAC fixes the signing problems encountered in OAuth 1.0a, yes there 
are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 
auth model and will provide for a single codepath for sites that want 
to use both Bearer and MAC.



*From:* Dick Hardt mailto:dick.ha...@gmail.com>>
*To:* William Mills >
*Cc:* "oauth@ietf.org " >

*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


On Aug 9, 2012, at 9:52 AM, William Mills wrote:

I find the idea of starting from scratch frustrating.  MAC solves a 
set of specific problems and has a well defined use case.  It's 
symmetric key based which doesn't work for some folks, and the 
question is do we try to develop something that supports both PK and 
SK, or finish the SK use case and then work on a PK based draft.


I think it's better to leave them separate and finish out MAC which 
is *VERY CLOSE* to being done.


Who is interested in MAC? People can use OAuth 1.0 if they prefer 
that model.


For my projects, I prefer the flexibility of a signed or encrypted 
JWT if I need holder of key.


Just my $.02

-- Dick



___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth






___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Justin Richer]

With MAC, you should be able to re-use about 80-90% of your existing 
codepath that's in place for Bearer, simplifying the setup below.


I would figure that the "variant of OAuth2" issue is a red herring 
because not everyone out there is fully spec compliant. If they were, 
you wouldn't have so many beautiful snowflakes.


 -- Justin

On 08/09/2012 03:48 PM, Dick Hardt wrote:
As an implementer, I have an app that accesses 10 different resources. 
Some are OAuth 1.0A, some are a variant of OAuth 2. All have a 
slightly different code path since each resource is its own beautiful 
snowflake. I did not use any libraries for OAuth 2. Supporting MAC 
would give me yet another library to integrate with.


I'd be interested in what signing problems OAuth 1.0A has. I have my 
own list of how writing to OAuth 1.0A is hard.


On Aug 9, 2012, at 10:53 AM, William Mills wrote:

MAC fixes the signing problems encountered in OAuth 1.0a, yes there 
are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 
auth model and will provide for a single codepath for sites that want 
to use both Bearer and MAC.



*From:* Dick Hardt mailto:dick.ha...@gmail.com>>
*To:* William Mills >
*Cc:* "oauth@ietf.org " >

*Sent:* Thursday, August 9, 2012 10:27 Aa
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


On Aug 9, 2012, at 9:52 AM, William Mills wrote:

I find the idea of starting from scratch frustrating.  MAC solves a 
set of specific problems and has a well defined use case.  It's 
symmetric key based which doesn't work for some folks, and the 
question is do we try to develop something that supports both PK and 
SK, or finish the SK use case and then work on a PK based draft.


I think it's better to leave them separate and finish out MAC which 
is *VERY CLOSE* to being done.


Who is interested in MAC? People can use OAuth 1.0 if they prefer 
that model.


For my projects, I prefer the flexibility of a signed or encrypted 
JWT if I need holder of key.


Just my $.02

-- Dick







___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth