Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

<Axel.Nennker@telekom.de> Thu, 13 May 2010 20:50 UTC

Return-Path: <Axel.Nennker@telekom.de>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791123A68E6 for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vox885MK86Mn for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:02 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8D6613A6832 for <oauth@ietf.org>; Thu, 13 May 2010 13:49:56 -0700 (PDT)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 May 2010 22:49:40 +0200
Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 22:49:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 May 2010 22:49:37 +0200
Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049FA5BA@S4DE9JSAAID.ost.t-com.de>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
thread-index: AcrwdLKxFih7IRblQsKaGWxu0kloVACUBeegAAWsfrA=
References: <4BE730CC.1090607@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET><4BE85A86.2020701@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Axel.Nennker@telekom.de
To: eran@hueniverse.com
X-OriginalArrivalTime: 13 May 2010 20:49:39.0404 (UTC) FILETIME=[CE2A18C0:01CAF2DD]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2010 20:50:03 -0000

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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Thursday, May 13, 2010 7:59 PM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt



> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth