Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Jun 2010 15:10:03 +0200
Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Thread-Topic: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05 (with
 updates)
Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgAW+JpA
References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: <Axel.Nennker@telekom.de>
To: <eran@hueniverse.com>, <oauth@ietf.org>
Subject: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)
Precedence: list

=20
During the meeting we had a (short) discussion about the expires_in =
parameter.
I propose to change it to a notonorafter parameter with a GMT/UTC date =
as value.
If the time slew between server is bigger or nearly equal to the life =
time of the expires_in value than the token receiver has no chance to =
detect that the token is dead on arrival.
Or we could keep the name expires_in but change the value from a =
relative unit (seconds) to a absolute one (Date)

-Axel

expires_in
         OPTIONAL.  The duration in seconds of the access token =
lifetime.

notonorafter
         OPTIONAL.  Specifies the time instant at which the assertion =
has expired in universal time coordinates.

Example
	notonorafter=3D"2007-08-21T08:18:50.605Z"



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Eran Hammer-Lahav
Sent: Tuesday, June 15, 2010 8:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates)

During the OAuth WG interim meeting, the group spent a considerable =
amount of time going over draft -05 and listing issues with the text and =
protocol. Since the draft is now significantly different, I want to go =
over this and identify the issues resolved and those still open (before =
it is too late).

These comments are based on Brian Eaton's detailed notes (thanks!) with =
my edits. I removed comments that were not actionable. I kept the names =
next to comments where additional clarifications are needed. If the =
notes are wrong, blame me for messing with the Brian's copy.

Action items are marked with ***.

Overall, I think by -09 we will be done with most of the comments (ready =
for another batch).

EHL

---

> Introduction:
>
> - Add purposes / use cases
> - Describe how it relates to other authentication schemes (OpenID, =
HTTP Auth)
> - Move requirements out of the introduction
> - Describe goals and possibilities
> - Clarify that the listed requirements are not the only ones

I'm generally happy with the current outline for the introduction. Those =
looking to address these points should submit text proposals.

> Terminology:
>
> - Define client secret

Client secret isn't a term but a detail of the client authentication =
process, especially with the way it is defined now.

> - Describe relationship between terms

The section has been restructured to add two levels of terms to show =
relationships.

> - Add verification code

The verification code was renamed to authorization code and added.

> - Remove terminology references to HTTP terms

Removed reliance on HTTP terminology.

> - Add cryptographic terms
> - User the term 'capability' when talking about bearer tokens

Since the signature and cryptography was removed, these comments are no =
longer relevant for this draft.

> Overview:
>
> - Does not related to the introduction (confusing)

The overview section was written from scratch so hopefully it is less =
confusing.

> - Standardization of tokens should be called out as defined elsewhere
> - Explain that the separation between the authorization server and =
resource server is out of scope

Both will be clarified in -09.

> - Flow grouping is confusing

Since the flows have been incorporated into the introduction, and the =
grouping removed, the confusion should be resolved.

> 3.2 End-user endpoint:
>
> - Rename 'end-user endpoint' to 'approval url'

Renamed to 'end-user authorization endpoint'.

> - No mandatory to implement language - interop problem (Peter St. =
Andre)

*** Please clarify what should be required.

> - Does not mention user identity (how to verify)

User identity is out of scope. Should be addressed by the proposed =
OpenID Connect work.

> - When using TLS, make sure it's server authentication, not client =
certificates (Eve Maler)

*** Please propose language.

> - 'user-uri' attribute is too experimental to be included

Moved to discovery draft.

> - Explain that the end-user endpoint is only relevant to some flows

I think -08 makes this clear.

> - Should standardize existing service provider specific parameters for =
UI, e.g. language, display type, user hint

Published in a separate UX draft.

> 3.3 Token endpoint:
>
> - First sentence ("After obtaining authorization from the resource =
owner") is not true for all flows

I think the same issue exists in -08 but I'm not sure how to address it. =
Is it really a problem?

> - Maybe change name to 'Token issuing endpoint'

I think token endpoint is nice and short.

> - MUST use SSL?

Changed to "Servers MUST support TLS 1.2" and may support other stuff =
(equally strong) as well.

> - Mandate POST?

Yes. Otherwise secrets leak into log files.

> 3.3.1 Client Authentication:
>
> - Need new text for certificate authentication
> - Need more flexible language

The latest draft fixes this by moving the client authentication out of =
the endpoints and into its own section. In addition, the client =
identifier and secret are given a name (basic client credentials) to =
make it easier to specify other ways to authenticate the client.

> 3.3.2 Response Format:
>
> - Do we need so many formats?
> - Are all formats needed on both sides?

Solved by using just JSON for token endpoint responses.

> - Is no-store enough of a cache-control header? (Chuck Mortimore)

*** No idea. Is it?

> 3.3.2.1 Access Token Response:
>
> - Define scope once, include by reference

Don't even need to reference anymore. Defined in a single place.

> - Need "scope" example (Hannes)

*** It is hard to provide scope examples. Are there any scopes common in =
more than one OAuth 1.0 implementation?

> - Scope is underspecified

It is as specified as we have consensus for (even this was painful).

> - Authorization server MUST honor client request for token secret?

Since this is moved to an extension, the answer is no.

> - Semantics of "expires_in" are underspecified

Added example in -09.

> 3.3.2.2 Error response:
>
> - Data format needs to be in sync across entire spec

Now uses JSON like a successful response.

> - Add debugging message field to JSON

Debugging is out of scope, but feel free to write a proposal.

> - Predefined list of error responses?

New section added in -07. Still needs to add text to describe each error =
message, as well as make the list complete.

> 3.4 Flow Parameters:
>
> - More on error handling? (Peter St. Andre)

*** Not sure what this is about.

> 3.5 User-Agent Flow:
>
> - If refresh token leaks, you can't recover. =A0Changing client secret =
is not enough.

No longer issuing refresh token in user-agent flow.

> - Can we change order of user-agent and web app flow in spec?

Done.

> - WRAP web server flow was more secure for rich-client apps, because =
web sites cannot pretend to be rich clients. =A0User-Agent flow does not =
allow this. (Sarah Faulkner)

*** Please start a new thread to discuss.

> - Where do we handle custom protocol schemes in redirect URIs?

*** Currently mentioned in native application section. Need guidance =
from IESG on how to handle this so it will not become a blocking issue.

> - Move installed applications to a separate section

Done.

> - Need to give installed app developers a way to specify device name =
(Brian Eaton)

*** Please propose text.

> - Can=A0mobile developers use HTTP URL discovery from slide deck =
instead? (Bill Keenan)

*** Need clarification.

> - Explain how to authenticate the client.
=20
I think the new text is pretty clear, using a reference to the client =
authentication section.

> 3.5.1 Client Requests Authorization:
>
> - What if malicious actor (either a user or "man in the browser") =
tampers with "scope" or "state" parameter? (Eve Maler)

Since the end-user gets to authorize the request, scope tempering =
shouldn't be a problem. As for state, I'm not sure.

> - Should we add an extension so that users can self-identify their =
device? (Bill Smith)

*** Please propose text or start a discussion.

> - Authorization servers MAY restrict the redirection URI to not =
include a
> query component. This will break PHP clients

This is part of the underspecified matching rules. I'll drop it for now.

> 3.5.1.1 End-user grants authorization:
>
> - seems odd that client is requesting the token secret.
> - what happens if server doesn't want to issue token secret?

Removed. Still an open question for the signature spec.

> - should we make example https?

I don't think this is necessary since the fragment is not transmitted.

> 3.5.1.2 End-user denies authorization:
>
> - More error codes needed (Sarah Faulkner and Marius Scurtescu)

*** Please provide text.

> - Immediate mode failure needs an error code

Removed. Noted for when the parameter appears on another draft.

> 3.5.2 Client extracts access token:
>
> - Can we tell user-agents not to send fragment in HTTP request? =A0IE =
does this
> in certain circumstances.

HTTP tells that. It was made more explicit in the new HTTPbis work. =
Beyond that, not sure what we can do.

> 3.6.1 Client Requests Authorization:
>
> - redirect_uri validation strategy should be described once in the =
spec, and then included by reference.

Done.

> - Some of the required parameters don't make sense if authentication =
of user is out of band. (Eve Maler)

The only required parameter there were 'client_id', 'type', and =
'redirect_uri'. Which one are you referring to?

> 3.6.1.1 - End-user grants authorization:
>
> - What does the verification code provide?

I think the new text explains this (part of the abstraction layer =
provided by the access grant). Let me know if it still needs to be =
clarified.

> - How do people keep verification code from leaking in referrer =
header? (Sarah Faulkner)

*** Is this an issue? Can you start a thread to discuss?

> - Should we define time-limit for verification code? =A05 minutes? =
(Peter St. Andre)

*** Open issue.

> - Specify that verification code should be used only once

Made even clearer in -09.

> 3.6.2 - Client requests access token:
>
> - should mention https

Done.

[Device flow feedback removed]

> 3.8 - Username and password flow:
>
> - need to return error URL from this flow, so that users can get their =
account unblocked if they are on the same IP range as a botnet (Brian =
Eaton)

*** Please suggest text.

> 3.10 - Assertion Flow:
>
> - we need an example

Done.

> - Two format parameters

Fixed.

> 4 - Refresh Token:
>
> - should we alway tell clients to use a secret, e.g. "anonymous" or =
"opensecret"? =A0Absent secret might be confusing? (Brian Eaton)

*** Please clarify.

> - Should we allow down-scoping on this endpoint?

-08 adds support for down-scoping.

> - Scope needs to be figured out through entire flow (Eve Maler)

*** -08 tries to clean up scope handling. Please review.

> 5 - Accessing a protected resource:
>
> - No clear error path

Noted. To be addressed in -09.

> - Should the authentication scheme name be called 'Token'?

I think so. Those who disagree are welcome to start a discussion.

> - Can we say "bearer tokens" MUST NOT be sent over secure channels? =
(Jim Fenton)

I would like that but consensus was that SHOULD NOT is the strongest we =
can specify.

> - Can we write a spec that reflects security reality - people do send =
bearer tokens over HTTP connections

We did :-(

> - Can we say MUST NOT send bearer tokens to unfamiliar sites?

Done in -09.

> - Is "unfamiliar" well-defined?

I think it is in the context of the spec - not hardcoded into the =
client.

> - Can we have a same-origin policy?

This needs to be addressed in the discovery spec. James' propose 'sites' =
parameter is one approach.

> 5.2 - Bearer Token Requests:
>
> - We should drop realm, it has no meaningful semantics here

*** I will float this past the HTTP folks to gage their reaction.

> 6.1 - WWW-Authenticate Response header:
>
> - what about resources that return public data if request is =
unauthenticated? POST vs GET might have different security policy.

*** Need to look into this.

> 6.1.1. - describing the WWW-Authenticate response header
>
> - Discovery needed for various elements

Yes. That's for the discovery draft.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth