Re: [OAUTH-WG] Multiple access tokens

[William Mills]

You might want to put issuance time and other info in an access token.  The 
spec is silent on your first question.

On revocation: One of the reasons for short lived access tokens is to only 
revoke the refresh token, which has to be presented at a central server type 
rather than trying to extend revocation to all protected resources.  So if 
you're in that model you would not bother revoking the access token.

The use case I can see for invalidating access tokens and still honoring 
refresh tokens is the case where you might have had the access token symmetric 
secret compromised but not the refresh token secret.  That's not really user 
revocation though.  I don't se an actual user revocation of access that would 
not potentially kill both tokens and always kill the refresh token.

 




- Original Message -
From: Ross Boucher 
To: OAuth WG 
Cc: 
Sent: Wednesday, March 7, 2012 6:14 PM
Subject: [OAUTH-WG] Multiple access tokens

The spec doesn't seem to have any recommendations on this point, but should an 
OAuth v2 API always return the same access token if the same client makes 
multiple requests? Is there any benefit to not generating a new access token 
for each request? Similarly, if you do generate new access tokens (as I am 
doing now), should you also generate new refresh tokens?

An unrelated question about revoking access tokens when the same authorization 
code is used more than once: should refresh tokens also be revoked? And, if so, 
should any tokens issued with that refresh token then also be revoked? It seems 
simpler (if slightly less correct) to just revoke all access tokens for that 
specific client/resource pair in that case, rather than tracking the ancestry 
of all tokens.

Thanks,
Ross
___
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] Multiple access tokens

[Torsten Lodderstedt]

Hi,



Ross Boucher  schrieb:

>The spec doesn't seem to have any recommendations on this point, but
>should an OAuth v2 API always return the same access token if the same
>client makes multiple requests? Is there any benefit to not generating
>a new access token for each request?

I don't see any.

>Similarly, if you do generate new
>access tokens (as I am doing now), should you also generate new refresh
>tokens?

Depends on the grant type. I would expect an authz server to generate new 
refresh tokens for "code", whether the authz server creates a new one for grant 
type "refresh_token" might depend on server impl. and client-specific policy 
(refresh token rotation).

>
>An unrelated question about revoking access tokens when the same
>authorization code is used more than once: should refresh tokens also
>be revoked? 

Does it make sense to not revoke refresh token? Otherwise, it could be used to 
obtain fresh access tokens.

> And, if so, should any tokens issued with that refresh
>token then also be revoked? It seems

:-) sounds reasonable but not nessessarily feasable

> simpler (if slightly less correct)
>to just revoke all access tokens for that specific client/resource pair
>in that case, rather than tracking the ancestry of all tokens.

Generally, I would consider revoking access tokens more difficult then revoking 
refresh tokens. It depends on your token design. One can use handles for 
refresh tokens and self-contained access tokens and revoke refresh tokens only. 
In that case, I would limit the access token lifetime in order to force a 
periodic refresh.

Regarding client/resource: 
Depends on whether you are able to really identify a particular client 
instance. Otherwise, you would revoke tokens for different (potentially a lot 
of) client installations using the same client_id.

regards,
Torsten.

>
>Thanks,
>Ross___
>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] I-D Action: draft-ietf-oauth-v2-24.txt

[Eran Hammer]

This draft is ready to go to IESG Review.

EH

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of internet-dra...@ietf.org
> Sent: Wednesday, March 07, 2012 9:42 PM
> To: i-d-annou...@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol Working Group of
> the IETF.
> 
>   Title   : The OAuth 2.0 Authorization Protocol
>   Author(s)   : Eran Hammer
>   David Recordon
>   Dick Hardt
>   Filename: draft-ietf-oauth-v2-24.txt
>   Pages   : 66
>   Date: 2012-03-07
> 
>The OAuth 2.0 authorization protocol enables a third-party
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>third-party application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 1.0 protocol described
>in RFC 5849.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt
> 
> ___
> 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] I-D Action: draft-ietf-oauth-v2-24.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : The OAuth 2.0 Authorization Protocol
Author(s)   : Eran Hammer
  David Recordon
  Dick Hardt
Filename: draft-ietf-oauth-v2-24.txt
Pages   : 66
Date: 2012-03-07

   The OAuth 2.0 authorization protocol enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 1.0 protocol described
   in RFC 5849.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt

___
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

[Eran Hammer]

Should simple read "the attacker's user-agent is sent to".

EH

> -Original Message-
> From: Songhaibin [mailto:haibin.s...@huawei.com]
> Sent: Wednesday, March 07, 2012 6:11 PM
> To: Eran Hammer; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org
> Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling
> Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23
> 
> > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is
> > > sent to.../ When the authorization code request is sent to...
> >
> > Not sure what you mean.
> 
> I mean you may have to change "the attacker is sent to..." to "the
> authorization code is sent to...".
> 
> BR,
> -Haibin
> 
> > -Original Message-
> > From: Eran Hammer [mailto:e...@hueniverse.com]
> > Sent: Thursday, March 08, 2012 8:16 AM
> > To: Songhaibin; tsv-...@tools.ietf.org;
> > draft-ietf-oauth...@tools.ietf.org
> > Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling
> > Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23
> >
> > Thanks Haibin.
> >
> > > -Original Message-
> > > From: Songhaibin [mailto:haibin.s...@huawei.com]
> > > Sent: Wednesday, February 15, 2012 1:33 AM
> >
> > > Nits:
> > > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it
> > > the authorization server who sends the request to the authorization
> endpoint?
> > > Or is it the resource owner?
> >
> > The client. Added clarification in section 3.
> >
> > > 2. Section 3.1.1, paragraph 3, "...where the order of values does not
> matter.."
> > > I think a little clarification on the reason for this would be
> > > better for people like me.
> >
> > I don't think we need to explain it, but it's to meet typical developers'
> > expectations.
> >
> > > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it
> > > the authorization server who sends request to the token endpoint?
> >
> > Same as #1.
> >
> > > 4. Section 10.12, paragraph 4, should the terminology "end-user" be
> > > changed to "resource owner"? There are same issues in other places
> > > of this document.
> >
> > Changed some. Clarified end-user in the intro.
> >
> > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is
> > > sent to.../ When the authorization code request is sent to...
> >
> > Not sure what you mean.
> >
> > EH
> >

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

Re: [OAUTH-WG] Quick question about error response for "response_type=unknown"

[Eran Hammer]

Section 3.1.1 states:

   If an authorization request is missing the "response_type" parameter,
   the authorization server MUST return an error response as described
   in Section 4.1.2.1.

The intention was to make this the catch-all scenario. While I do appreciate 
the issue here of the client using a response type that may require special 
encoding of the error information in the response, it is pretty easy to also 
support the authorization code response type error transport when using a 
response type other than code and token.

I have made the following change to clarify this:

   If an authorization request is missing the "response_type" parameter,
   [[or if the response type is not understood, ]]
   the authorization server MUST return an error response as described
   in Section 4.1.2.1.

"Not understood" means the server does not know anything about it. It should 
know about code and token, even if one or both are not supported and provide 
the required error response. This really is only about unknown extensions. Then 
according to section 4.1.2.1, the error code should be 
'unsupported_response_type'.

I have tried to make the change as small as possible, but if my explanation 
isn't clear from the new text, please let me know and we'll get it clarified.

EH


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
matake@gmail
Sent: Tuesday, February 21, 2012 4:23 AM
To: Buhake Sindi
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Quick question about error response for 
"response_type=unknown"

When server cannot understand the response_type, it can't know where the error 
response should be included.

ex.)
A JS client used response_type=code%20id_token and expected all returned 
parameters would be included in fragment.
However server couldn't understand the response_type and returned error 
messages in query.
Then client won't be able to handle the error.

Actually, clients expects returned parameters in query only when it uses 
response_type=code, at least in current proposed response_types.
(I'm thinking "current proposed response_types" as "code", "token", "code 
token", "token id_token", "code id_token" and "code token id_token")


On 2012/02/21, at 20:42, Buhake Sindi wrote:


Oops. Sorry, I believe I should have said, case 2.

And why is case 2 impossible? The only time case 1 is valid in the redirect_uri 
is invalid.

Buhake Sindi
On 21 February 2012 13:40, Buhake Sindi 
mailto:buh...@googlemail.com>> wrote:
Hi guys,

OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states:
If the request fails due to a missing, invalid, or mismatching redirection URI, 
or if the client
identifier is missing or invalid, the authorization server SHOULD inform the 
resource owner of
the error, and MUST NOT automatically redirect the user-agent to the invalid 
redirection URI.

So, Case 1 is the only accepted case here.

Buhake Sindi


On 21 February 2012 13:34, matake@gmail 
mailto:mat...@gmail.com>> wrote:
So the answer is "Show the error to the user without redirecting back to the 
client", right?
I'm now developing OAuth2 and OpenID Connect ruby library, and both of them 
return errors

case 1. redirect with error in query if response_type is "code" but it's not 
supported
case 2. redirect with error in fragment if response_type is "token code", 
"token id_token", "token code id_token" or "code id_token" but it's not 
supported
case 3. otherwise show error to the user without redirect since server cannot 
understand the response_type at all

But other server might not understand some of response_types listed in case 2 
at all and choose case 3 in such case.
(ie. OAuth servers which don't understand OpenID Connect won't understand 
"id_token")

So I'm afraid that it reduces interoperability, a bit.

On 2012/02/21, at 13:22, William Mills wrote:


I does allow some parts of your server config to be discovered.  More of a 
problem in error responses is usually echoing back the user data, or allowing 
user enumeration for example.  Care is required, but you don't have a ton of 
options here.


From: Igor Faynberg 
mailto:igor.faynb...@alcatel-lucent.com>>
To: oauth@ietf.org
Sent: Monday, February 20, 2012 9:37 AM
Subject: Re: [OAUTH-WG] Quick question about error response for 
"response_type=unknown"

Could there be a potential security hole in providing an error response?  (Not 
that I see it, but many problems in the past had been caused by helpful 
responese.)

Igor

On 2/20/2012 11:57 AM, William Mills wrote:
Respond with an error in protocol.  Thta won't include a redirect, and the 
client has to know what to do.


From: nov matake 
To: oauth WG 
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for 
"response_type=unknown"

Hi OAuthers,

My apologies if you already discussed this.

When OAuth server received u

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

[Songhaibin]

OK. I understand. Then I have no questions. 

Thank you for the answer.
-Haibin

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Eran Hammer
> Sent: Thursday, March 08, 2012 8:02 AM
> To: Songhaibin; Justin Richer
> Cc: draft-ietf-oauth...@tools.ietf.org; tsv-...@tools.ietf.org; 
> tsv-...@ietf.org;
> oauth@ietf.org; Martin Stiemerling
> Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> 
> 
> > -Original Message-
> > From: Songhaibin [mailto:haibin.s...@huawei.com]
> > Sent: Friday, February 17, 2012 12:53 AM
> > To: Justin Richer
> > Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin
> > Stiemerling; oauth@ietf.org; tsv-...@ietf.org
> > Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> >
> > Hi Justin,
> >
> > Thank you for the clarification. See in line.
> >
> > > -Original Message-
> > > From: Justin Richer [mailto:jric...@mitre.org]
> > > Sent: Wednesday, February 15, 2012 9:44 PM
> > > To: Songhaibin
> > > Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin
> > > Stiemerling; oauth@ietf.org; tsv-...@ietf.org
> > > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> > >
> > > 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.
> > >
> >
> > Okay, in the Resource Owner Password Credentials flow, it adds client
> > credentials, but any client who was issued credentials from the 
> > authorization
> > server can pass. How much security does the client credential in this flow
> > add?
> 
> It can allow the server to enforce policies, but more importantly, client
> authentication is part of every access token request make to this endpoint as
> part of the overall architecture.
> 
> > > > 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.
> > >
> >
> > Yes, I understa

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

[Eran Hammer]

New text:

  The probability of an attacker guessing generated tokens (and other 
credentials not
  intended for handling by end-users) MUST be less than or equal to 
2^(-128) and SHOULD be
  less than or equal to 2^(-160).

Removed reference to RFC 1750.

EH

> -Original Message-
> From: John Bradley [mailto:ve7...@ve7jtb.com]
> Sent: Monday, February 06, 2012 5:07 PM
> To: Eran Hammer
> Cc: Julian Reschke; i...@ietf.org; The IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Last Call:  (The
> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
> 
> RE new text in Draft 23
> 
> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10
> 
> Generated tokens and other credentials not intended for handling by
>end-users MUST be constructed from a cryptographically strong random
>or pseudo-random number sequence ([RFC1750]) generated by the
>authorization server.
> 
> Given that many implementations may elect to use signed tokens, such as
> SAML or JWT (JOSE) this should not be a MUST.
> 
> Giving people sensible defaults such as the probability of an attacker
> guessing a valid access token for the protected resource should be less than
> 2^(-128).
> 
> The probability of generating hash colisions randomly is a odd metric,  2^(-
> 128) for a SHA256 as I recall.
> Many factors play into what is secure, token lifetime etc.
> 
> I don't mind some reasonable defaults but adding a requirement for
> unstructured tokens is a bit much.
> 
> Regards
> John B.
> 
> 

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

[OAUTH-WG] Multiple access tokens

[Ross Boucher]

The spec doesn't seem to have any recommendations on this point, but should an 
OAuth v2 API always return the same access token if the same client makes 
multiple requests? Is there any benefit to not generating a new access token 
for each request? Similarly, if you do generate new access tokens (as I am 
doing now), should you also generate new refresh tokens?

An unrelated question about revoking access tokens when the same authorization 
code is used more than once: should refresh tokens also be revoked? And, if so, 
should any tokens issued with that refresh token then also be revoked? It seems 
simpler (if slightly less correct) to just revoke all access tokens for that 
specific client/resource pair in that case, rather than tracking the ancestry 
of all tokens.

Thanks,
Ross

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Ignoring unrecognized request parameters

[Eran Hammer]

Our "mustUnderstand" is extension grant types. Define a new one and everything 
will break if the server doesn't understand something as defined by the new 
grant type spec.

EH

From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Saturday, February 18, 2012 3:41 PM
To: Eran Hammer
Cc: William Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters

It is a general problem with security protocols like SOAP, SAML, X.509.

Sometimes when you define an extension you want to be certain that the 
Authorization server understands it,  or you want an error.

As an example if someone did a authentication context extension (Not proposing 
it just an example).   They would perhaps rather have an error if the 
Authorization server did not understand the extension,  they could then retry 
without the extension if that worked for them.

This is generally dealt with by marking something as 
mustUnderstand in 
SOAP or critical in x.509.

Without that functionality (I am not asking to add it) it may be reasonable for 
some Authorization servers to return an error if they do not completely 
understand what is being sent to them.

One school of thought feels that anything you don't understand in a message 
could be an indication of a problem or tampering.

I am sympathetic to the Forward compatibility argument,  however without some 
sort of mustUnderstand semantics it is not going to always work.

One thing that might help is an error message to indicate that it is being 
rejected due to unknown extensions so a client can retry.

John B.


On 2012-02-16, at 8:01 PM, Eran Hammer wrote:


Can you give an example where an unknown parameter being ignored can lead to 
security issues?

EH


From: John Bradley mailto:ve7...@ve7jtb.com>>
Date: Thu, 16 Feb 2012 11:55:21 -0700
To: William Mills mailto:wmi...@yahoo-inc.com>>
Cc: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Ignoring unrecognized request parameters

If you have a generic client that works across multiple Authorization endpoints 
some that have extension X and others not, I can see that having the 
Authorization servers ignore unknown parameters is desirable.

However there are some endpoints that are not going to be able to allow unknown 
parameters due to there security policy.   They are often a indication of an 
attack.

If this remains a MUST then some endpoints will have to ignore it, and be non 
compliant.

I would be OK with something like "MUST ignore unknown parameters unless the 
endpoint is required to return an error due to local security policy."

There is probably no perfect compromise on this one.

John B.


On 2012-02-16, at 3:32 PM, William Mills wrote:


No, this is required for forward compatibility.  Implementations that send 
extended parameters like capability advertisements (i.e. CAPTCHA support or 
something) shoudl not be broken hitting older implementations.


From: Mike Jones 
mailto:michael.jo...@microsoft.com>>
To: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Sent: Thursday, February 16, 2012 10:16 AM
Subject: [OAUTH-WG] Ignoring unrecognized request parameters

In core -23, the last paragraph of section 
3.1 now says:

The authorization server MUST ignore unrecognized request 
parameters.

In -22, this said:

The authorization server SHOULD ignore unrecognized request 
parameters.

In a security protocol, it seems unreasonable to require that information be 
ignored.  As I see it, it SHOULD be legal to return an error if unrecognized 
information is received.

Why the change?  And can we please have it changed back to SHOULD in -24?

Thanks,
-- 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


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

Re: [OAUTH-WG] Section 10.3 client advice inapplicable?

[Eran Hammer]

Removed 'and lifetime'.

EH

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Andrew Arnott
Sent: Sunday, February 19, 2012 7:09 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Section 10.3 client advice inapplicable?

>From draft 23, section 10.3:

The client SHOULD request access tokens with the minimal scope and lifetime 
necessary. The authorization server SHOULD take the client identity into 
account when choosing how to honor the requested scope and lifetime, and MAY 
issue an access token with a less rights than requested.

I can't find the part in the spec where the client can request access tokens in 
such a way as to influence the lifetime.  Why is the client then being advised 
in the above section to minimize the lifetime of the access tokens it asks for?

--
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

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

[Songhaibin]

> > 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent
> > to.../ When the authorization code request is sent to...
> 
> Not sure what you mean.

I mean you may have to change "the attacker is sent to..." to "the 
authorization code is sent to...".

BR,
-Haibin

> -Original Message-
> From: Eran Hammer [mailto:e...@hueniverse.com]
> Sent: Thursday, March 08, 2012 8:16 AM
> To: Songhaibin; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org
> Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling
> Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23
> 
> Thanks Haibin.
> 
> > -Original Message-
> > From: Songhaibin [mailto:haibin.s...@huawei.com]
> > Sent: Wednesday, February 15, 2012 1:33 AM
> 
> > Nits:
> > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the
> > authorization server who sends the request to the authorization endpoint?
> > Or is it the resource owner?
> 
> The client. Added clarification in section 3.
> 
> > 2. Section 3.1.1, paragraph 3, "...where the order of values does not 
> > matter.."
> > I think a little clarification on the reason for this would be better for 
> > people
> > like me.
> 
> I don't think we need to explain it, but it's to meet typical developers'
> expectations.
> 
> > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the
> > authorization server who sends request to the token endpoint?
> 
> Same as #1.
> 
> > 4. Section 10.12, paragraph 4, should the terminology "end-user" be changed
> > to "resource owner"? There are same issues in other places of this
> > document.
> 
> Changed some. Clarified end-user in the intro.
> 
> > 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent
> > to.../ When the authorization code request is sent to...
> 
> Not sure what you mean.
> 
> EH
> 

___
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

[Eran Hammer]

Thanks Haibin.

> -Original Message-
> From: Songhaibin [mailto:haibin.s...@huawei.com]
> Sent: Wednesday, February 15, 2012 1:33 AM

> Nits:
> 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the
> authorization server who sends the request to the authorization endpoint?
> Or is it the resource owner?

The client. Added clarification in section 3.

> 2. Section 3.1.1, paragraph 3, "...where the order of values does not 
> matter.."
> I think a little clarification on the reason for this would be better for 
> people
> like me.

I don't think we need to explain it, but it's to meet typical developers' 
expectations.

> 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the
> authorization server who sends request to the token endpoint?

Same as #1.

> 4. Section 10.12, paragraph 4, should the terminology "end-user" be changed
> to "resource owner"? There are same issues in other places of this
> document.

Changed some. Clarified end-user in the intro.

> 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent
> to.../ When the authorization code request is sent to...

Not sure what you mean.

EH


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

Re: [OAUTH-WG] Server cret verification in 10.9

[Eran Hammer]

New text:

  In order to prevent man-in-the-middle attacks, the authorization 
server MUST implement
  and require TLS with server authentication as defined by  for
  any request sent to the authorization and token endpoints. The client 
MUST validate the
  authorization server's TLS certificate as defined by , and in
  accordance with its requirements for server identity authentication.

EH

> -Original Message-
> From: John Bradley [mailto:ve7...@ve7jtb.com]
> Sent: Tuesday, January 24, 2012 2:24 PM
> To: Peter Saint-Andre
> Cc: Eran Hammer; OAuth WG
> Subject: Re: [OAUTH-WG] Server cret verification in 10.9
> 
> We added the reference to RFC6125 in openID Connect.
> 
> The Client MUST perform a TLS/SSL server certificate check, per
>   RFC 6125.
> 
> We wanted to be more general to allow for non http bindings in the future.
> 
> If you don't do it in core, every spec that references core will probably have
> to add it.
> 
> John B.
> 
> 
> On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote:
> 
> > On 1/20/12 4:46 PM, Eran Hammer wrote:
> >> Stephen asked:
> >>
> >>> (13) 10.9 says that the client MUST verify the server's cert which is
> >>> fine. However, does that need a reference to e.g. rfc 6125? Also, do
> >>> you want to be explicit here about the TLS server cert and thereby
> >>> possibly rule out using DANE with the non PKI options that that WG
> >>> (may) produce?
> >>
> >> Can someone help with this? I don't know enough to address.
> >
> > The OAuth core spec currently says:
> >
> >   The client MUST validate the authorization server's
> >   TLS certificate in accordance with its requirements
> >   for server identity authentication.
> >
> > RFC 2818 has guidance about endpoint identity, in Section 3.1:
> >
> > http://tools.ietf.org/html/rfc2818#section-3.1
> >
> > RFC 6125 attempts to generalize the guidance from RFC 2818 and many
> > similar specs for use by new application protocols. Given that OAuth as
> > defined by the core spec runs over HTTP, I think referencing RFC 2818
> > would make sense. So something like:
> >
> >   The client MUST validate the authorization server's
> >   TLS certificate in accordance with the rules for
> >   server identity authentication provided in Section 3.1
> >   of [RFC2818].
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> > ___
> > 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] error response for invalid refresh token

[Eran Hammer]

Invalid_grand is correct.

EH

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Buhake Sindi
Sent: Tuesday, February 21, 2012 7:16 AM
To: Peter Brindisi
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] error response for invalid refresh token

Hi
invalid_grant

The provided authorization grant (e.g. authorization code,
resource owner credentials) is invalid, expired, revoked, does
not match the redirection URI used

I would think that the refresh_token is an authorization code that needs 
refreshing, so this would be valid.


On 21 February 2012 15:33, Peter Brindisi 
mailto:peter.brind...@gmail.com>> wrote:
Hi all,

I am currently implementing version 23 of the oauth2 spec, and I came across a 
bit of ambiguity. What is the appropriate error code for an invalid refresh 
token? I am unsure whether it should be 'invalid_grant' or 'invalid_request'. 
Neither seems 100% clear.

Thanks in advance!

Best,
Peter

___
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] How an AS can validate the state parameter?

[Eran Hammer]

Can't validate, but can sanitize.

EH

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Andrew Arnott
Sent: Sunday, February 19, 2012 7:36 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] How an AS can validate the state parameter?

>From section 10.14: (draft 23)
The Authorization server and client MUST validate and sanitize any value 
received, and in particular, the value of the state and redirect_uri parameters.

Elsewhere in the spec the AS is instructed to exactly preserve the state and to 
consider it an opaque value.  How then, can an AS validate and sanitize the 
state parameter?

--
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

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

[Eran Hammer]

> -Original Message-
> From: Songhaibin [mailto:haibin.s...@huawei.com]
> Sent: Friday, February 17, 2012 12:53 AM
> To: Justin Richer
> Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin
> Stiemerling; oauth@ietf.org; tsv-...@ietf.org
> Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> Hi Justin,
> 
> Thank you for the clarification. See in line.
> 
> > -Original Message-
> > From: Justin Richer [mailto:jric...@mitre.org]
> > Sent: Wednesday, February 15, 2012 9:44 PM
> > To: Songhaibin
> > Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin
> > Stiemerling; oauth@ietf.org; tsv-...@ietf.org
> > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> >
> > 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.
> >
> 
> Okay, in the Resource Owner Password Credentials flow, it adds client
> credentials, but any client who was issued credentials from the authorization
> server can pass. How much security does the client credential in this flow
> add?

It can allow the server to enforce policies, but more importantly, client 
authentication is part of every access token request make to this endpoint as 
part of the overall architecture.

> > > 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.
> >
> 
> Yes, I understand that. But the document seems like resource owner is the
> "only" one who can run the UA app or native app? Or I missed something?

It is the only one. Only the resource owner can grant access.

EH

> 
> Thanks,
> -Haibin
> 
> >
> > 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] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4)

[Eran Hammer]

Added:

unsupported parameter value (other than grant type)

EH


> -Original Message-
> From: Roger Crew [mailto:c...@cs.stanford.edu]
> Sent: Tuesday, February 07, 2012 12:53 PM
> To: Eran Hammer
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension
> response types (8.4)
> 
>  > > (2) [in 4.2.2.1]  If the response_type is provided but unknown,
>  > > is that an 'invalid_request' (since this is clearly an
>  > > "unsupported parameter value") or is it an
>  > > 'unsupported_response_type'?
>  > >
>  > > Seems to me it should be the latter.  If so, then...
>  > > ...
>  > > should the description for 'invalid_request' even be referring to
>  > > "unsupported" values at all?
>  > > ...
>  > > Section 5.2 has the same problem w.r.t. 'unsupported_grant_type'
>  >
>  > Changed the definition of invalid_request to:
>  >
>  >   The request is missing a required parameter, includes an invalid
>  >   parameter value, or is otherwise malformed.
> 
> Just noticed in draft 23 that you changed 4.2.2.1 but didn't change 5.2, which
> still refers to "unsupported" parameter values and thus similarly conflicts
> with the definition of 'unsupported_grant_type'.
> 
> 
> --
> Roger Crew
> c...@cs.stanford.edu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Barry Leiba]

Henry says...
>> No, I appreciate that you want to use registered short names in the protocol,
>> that's just fine.  My problem is that you have left users, developers etc. 
>> with
>> no way to discover what shortnames have been registered short of a non-
>> trivial and error-prone informal search effort.
>>
>> What I'm asking for is support for probe URI prefixes for each family of
>> shortnames.  So, just as today I use "text/n3" as the media type for my
>> Notation3 documents, I can check that this is a registered media type by
>> attempting to retrieve
>>
>>  http://www.iana.org/assignments/media-types/text/n3
>>
>> and I can see all the registered text types by retrieving from
>>
>>  http://www.iana.org/assignments/media-types/text
>>
>> likewise I ought to be able to check e.g. the "bearer" token type by
>> attempting retrieval from (something along the lines of)
>>
>>  http://www.iana.org/assignments/access-token-types/bearer
>>
>> and I should be able to see all the registered token types by retrieving from
>>
>>  http://www.iana.org/assignments/access-token-types
>>
>> Hope this clarifies what I meant.

Eran says...
> Not sure I understand what you are asking for, but what would the IANA 
> instruction include to support this?

Yeh, I'm not understanding this either.  The spec establishes an
access-token-type registry, and anyone will be able to look in that
registry the same way they look in any other IANA registry, such as
media-types.  It looks like Henry is asking for this to use some sort
of type/subtype mechanism, as media-types does, wherein when a new
token type is registered, that registration or subsequent ones can
create subtypes of that token type.

But it's not clear that such a type/subtype scheme would always apply
here, as it does with media types.  Some token types will have no
subtypes.  What makes more sense is for the token types that need to
create their own sub-registries to do so.  And then those entries will
be found from IANA as well -- no error-prone informal search effort
should be needed.

Or am I missing the same thing Eran is?

Barry
___
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

[Eran Hammer]

> -Original Message-
> From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk]
> Sent: Tuesday, February 14, 2012 9:07 AM

> >> 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.
> 
> No, I appreciate that you want to use registered short names in the protocol,
> that's just fine.  My problem is that you have left users, developers etc. 
> with
> no way to discover what shortnames have been registered short of a non-
> trivial and error-prone informal search effort.
> 
> What I'm asking for is support for probe URI prefixes for each family of
> shortnames.  So, just as today I use "text/n3" as the media type for my
> Notation3 documents, I can check that this is a registered media type by
> attempting to retrieve
> 
>  http://www.iana.org/assignments/media-types/text/n3
> 
> and I can see all the registered text types by retrieving from
> 
>  http://www.iana.org/assignments/media-types/text
> 
> likewise I ought to be able to check e.g. the "bearer" token type by
> attempting retrieval from (something along the lines of)
> 
>  http://www.iana.org/assignments/access-token-types/bearer
> 
> and I should be able to see all the registered token types by retrieving from
> 
>  http://www.iana.org/assignments/access-token-types
> 
> Hope this clarifies what I meant.
> 

Not sure I understand what you are asking for, but what would the IANA 
instruction include to support this?

EH
___
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

[Paul Madsen]

+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.

I agree that an example response from the token endpoint would be
worthwhile.  Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?

  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
"access_token":"vF_9.5dCf-t4.qbcmT_k1b",
"token_type":"example",
"expires_in":3600,
"refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",
  }

It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:

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

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

[Brian Campbell]

Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.

I agree that an example response from the token endpoint would be
worthwhile.  Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"vF_9.5dCf-t4.qbcmT_k1b",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"stGzv3xOdkF0X35Qp2TlKWIA",
 }

It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.


* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3


On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer  wrote:
> 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-bo

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] question about the b64token syntax in draft-ietf-oauth-v2-bearer

[William Mills]

works for me.

 


P.S. Please start using the 
http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest  for new 
requests like product and feature  reviews.




 From: Brian Campbell 
To: William Mills  
Cc: Mike Jones ; oauth  
Sent: Wednesday, March 7, 2012 9:16 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in 
draft-ietf-oauth-v2-bearer
 
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_t

Re: [OAUTH-WG] Status of OAUTH re-charter discussion

[Hannes Tschofenig]

I was planning to kick of a discussion next week with a strawman proposal for a 
new charter text. 

Ciao
Hannes

On Mar 7, 2012, at 8:36 PM, Thomas Hardjono wrote:

> What is the status of the OAUTH WG re-charter efforts? The last thread was 
> back in October.
> 
> Will the re-charter be on the IETF-Paris agenda? (or will it be pushed out to 
> the July 2012 IETF).
> 
> Thanks.
> 
> /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-WG] Status of OAUTH re-charter discussion

[Thomas Hardjono]

What is the status of the OAUTH WG re-charter efforts? The last thread was back 
in October.

Will the re-charter be on the IETF-Paris agenda? (or will it be pushed out to 
the July 2012 IETF).

Thanks.

/thomas/

__


___
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

[Brian Campbell]

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_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://too