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="2007-08-21T08:18:50.605Z"
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, June 15, 2010 8:35 AM
To: OAuth WG ([email protected])
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. Changing 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. User-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 mobile developers use HTTP URL discovery from slide deck instead? (Bill
> Keenan)
*** Need clarification.
> - Explain how to authenticate the client.
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? IE 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? 5 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"? Absent 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
