On 2010-05-09, at 3:25 PM, Eran Hammer-Lahav wrote: > >> 3.2.1.1. Access Token Response >> expires_in >> OPTIONAL. The duration in seconds of the access token >> lifetime. >> >> refresh_token >> OPTIONAL. The refresh token used to obtain new access tokens >> using the same end-user access grant as described in Section 6. >> >> What is the exact meaning/idea of OPTIONAL response parameters? >> Who actually decides to use them? The client or the authorization server or >> both? >> Is it optional to implement this feature or is it envisioned the server >> dynamically decides to use those parameters based on its policy? > > Optional means the server gets to decide to include them or not. I think it > is pretty clear that optional is decided by the entity constructing the > message. > >> expires_in >> >> Why is there information passed back about the access tokens duration but >> not about the refresh tokens duration? > > No one asked for that. Is there interest in specifying the authorization > duration in addition to the token duration?
I have not heard of a scenario where it would be useful to the client to know the refresh token duration. Unlike the access token where the AS usually sets as expiry time. Authorization could be cancelled at any time for a wide variety of reasons, so there is little knowledge or certainty when it will expire. > >> 3.5. User-Agent Flow >> >> These clients >> cannot keep client secrets confidential and the authentication of the >> client is based on the user-agent's same-origin policy. >> >> Does this still hold in the context of "HTTP Origin Headers" >> (http://www.petefreitag.com/item/702.cfm)? >> >> BTW: Will Brian's security considerations document be updated to be in sync >> with the draft? > > Brian's document was written for WRAP. We need to write a full security > review for 2.0 that is structure similarly to OAuth 1.0. Besides changing some terminology, I would think Brian's doc would be mainly reusable. Perhaps you could insert a version with changes you understand, then people can suggest changes that need to be made. > >> 3.5.1. Client Requests Authorization >> >> If the client has previously registered a redirection URI with the >> authorization server, the authorization server MUST verify that the >> redirection URI received matches the registered URI associated with >> the client identifier. >> >> Does this mean equality? Or just the same base string? > > Right now it depends on the server. The spec should clarify that. Suggested wording: If the client has previously registered a redirection URI with the authorization server, the authorization server MUST verify that the redirection URI received matches the registered URI associated with the client identifier. The components of the redirection URI that must match the registered URI is authorization server dependant. > >> 7. Refreshing an Access Token >> >> I would suggest to add an optional "scope" parameter to this request. >> This could be used to downgrade the scope associated with a token. > > That would be the wrong way to do it given that people will expect to also be > able to upgrade scope. Would you elaborate? Would not providing a scope parameter enable any potential change in scope to the access token? The change may be neither an upgrade or downgrade, just different. > >> 8.1. The Authorization Request Header >> >> I consider the name "Token" of the authentication schema much to generic. >> That was also the feedback of all colleagues I talked to about the upcoming >> standard. Why not call it "OAuth2"? > > It is meant to be generic. I consider OAuth to be the part of the protocol > dealing with getting a token. There will be many new ways to get a token in > the future. I also find the use of Token here. > >> 8.2.2. Form-Encoded Body Parameter >> >> I would suggest to drop this section/feature. >> >> General note: Would it make sense to add explicit format handling to the >> OAuth API? If we envision authorization servers supporting more than one >> token format (e.g. SAML, SWT, ...), the client should given the option to >> request a certain format and responses returning access tokens should >> indicate the format of this token. The OAuth authorization header could also >> have an optional format attribute for the same purpose. > > You mean token format? OAuth defined the token as opaque so that would be > counter-productive. Not only can the AS support multiple formats, but a PR could support multiple formats. While the token is opaque to the client, the PR is going to need to detect what kind of token was presented in some way. We can make this easier by something in the spec, or defer this to the PR to detect tokens by examining the token. The scope parameter could be used by the AS to determine the token type to be generated. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
