Two snippets from the emails below:
> > You mean token format? OAuth defined the token as opaque so that
> would be counter-productive.
My comment on that comment:
"opaque" for oauth could mean that oauth does not handle certain
types of tokens specially.
I think this is not an argument to reject the request that the
client could ask for one token format.
I think a client should be allowed to ask for a token format but
oauth should not handle any format specially.
Oauth should transport all tokens but the format is something
agreed upon between client, authorization server and resource server.
Requesting a token format is also a means to migrate from one
token format to the next.
>> I dont't mean OAuth shall define token formats. I just ask for a way
to
>> request tokens in a particular format and pass such meta data from AS
to
>> resource server via the client. Why is that counter-productive?
>> Otherwise the resource server has to implement some token format
>> discovery.
>
>Yes it does.
>
>EHL
My comment on that comment:
If we burden the resource server with token format discovery then why
not burdon the authorization server with client_credential discovery?
Currently if client_secrets are used the client maker has to register
the client with the authorization server maintainer to get the
client_secret and such. This agreement is beyond the scope of oauth. I
think client and authorization server should be allowed to agree on any
authentication scheme not just shared secrets.
My request is to just rename client_secret to client_credential; both of
them know what they agreed upon whether it is a shared secret or
something else.
-Axel
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Eran Hammer-Lahav
Sent: Thursday, May 13, 2010 7:59 PM
To: Torsten Lodderstedt
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email protected]]
> Sent: Monday, May 10, 2010 12:12 PM
> >> 3.6.1.1. End-user Grants Authorization
> >>
> >> Why not call the "code" Parameter "verification_code"? It's called
> >> verification code in the text.
> >>
> > Longer for no reason.
> >
>
> for the sake of clarity?
Anyone with thoughts on this?
> >> 3.6.2. Client Requests Access Token
> >>
> >> client_secret
> >> REQUIRED if the client identifier has a matching secret.
The
> >> client secret as described in Section 3.4.
> >>
> >> 1) I'm having trouble to understand the meaning of "if the client
> >> identifier has a matching secret". Is the assumption underneath
that
> >> authorization servers require this secrets from all clients they
have issued
> a secret to?
Yes.
> >> What about client w/o a secret? Are they also allowed to use this
flow?
> >> Or is there envisioned a dependency
> >> between the client type, clients credentials and the flows a
> >> particular client is authorized to use?
Yes, they are (I think this is the compromise on native apps).
> >> I would have expected a clear policy which flows require
> >> authentication and which not.
Suggest text.
> >> 3.7.2. Client Requests Access Token
> >>
> >> "authorization_declined"
> >>
> >> Why does the spec interpret a request as bad request if the user
just
> >> has declined the authorization? According to rfc2616 the semantics
of
> >> 400 is: "The request could not be understood by the server due to
> >> malformed syntax".
> >>
> >> The calling client did not sent a malformed request, it cannot
> >> foresee or influence this outcome. I would suggest to either use
> >> status 403 or to return status code 200 for all syntactically
correct
> >> and authorized request and to use another return codes in the
response
> body to detail the requests outcome.
> >>
>
> Did you miss this question?
No. Just ignored it because I need to go over all the HTTP status codes
and error messages and clean it all up. Its incomplete at best right
now.
> >> 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.
> >
>
> What would be the right way?
Allow the client to include an access token when asking for additional
scope (via a normal flow) so that resulting token will include the scope
of both new and old scopes.
> >> 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.
> >
>
> That's interesting! I consider the authentication scheme the major
> contribution of OAuth since it allows for a standardized way of
service
> interaction. So 3rd party software components can be integrated into a
> companies infrastructure (incl. AS) w/o customization. Moreover, as
you
> pointed out, there will be many other ways to get tokens in the
future.
I'm not married to the name. I dislike 'OAuth2' because it is wrong to
put a version number in the name. We can potentially reuse 'OAuth' but
I'm opposed to using the 'oauth_version=2.0' parameter specified in
OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note
that 1.0 uses the oauth_ prefix for parameters and deprecate the
oauth_version parameter. Or something like that.
I'm also open to new suggestions. But I think 'Token' is very
descriptive (but I agree it does depend on your view of what is OAuth -
I think it is really just the collection of flows).
> >
> >> 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.
> >
>
> I dont't mean OAuth shall define token formats. I just ask for a way
to
> request tokens in a particular format and pass such meta data from AS
to
> resource server via the client. Why is that counter-productive?
> Otherwise the resource server has to implement some token format
> discovery.
Yes it does.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
