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