Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

["Richer, Justin P." <[e-mail]>]

The redirect URI is built into the structure of the client_id that the client passes that the AS can parse and check. Think of it as effectively using a structure analogous the software statement as the client_id itself, which you independently proposed as part of your client association draft's discussion sections (for transient clients in your use case, stateless auth servers in this use case).

Authentication of the client is separate, the open question is how people want to communicate the client's authentication credentials to the client in a way that the AS can later recognize. Some people were getting hung up on stuffing the client secret itself into the client_id, in which case you'd need to encrypt the client_id's structure to hide the secret. There are plenty of alternatives though, including just not using client secrets for stateless auth servers (where they don't make as much sense anyway).

 -- Justin

On Nov 4, 2013, at 2:06 PM, Phil Hunt <[e-mail]<mailto:[e-mail]>>
 wrote:

So how is a stateless client able to do the authorize flow?  How does the server know about the redirect_url?  Is it wide open?

Still would like to hear more about this.  Sometimes attacking the problem from a different direction leads to an innovative conclusion.

Still I share the concerns of Tony and binding authentication into client_id.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[e-mail]<mailto:[e-mail]>

On 2013-11-04, at 1:58 PM, Nat Sakimura <[e-mail]<mailto:[e-mail]>> wrote:

I was assuming that the AS uses symmetric encryption as it is faster and it just needs to be encrypted and decoded by itself.


2013/11/5 John Bradley <[e-mail]<mailto:[e-mail]>>
If the AS is using asymmetric encryption you need to both sign and then encrypt as anyone can encrypt.

Yes if the client has a TLS cert you could use a jwk_uri to keep the size down.

John B.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura <[e-mail]<mailto:[e-mail]>> wrote:

Since the client_id is supposed to be opaque, it would probably be better to JWE encrypt (note: all JWE encryption are integrity protected as well) by the authorization server upon issuing it to the client. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case.

I see this more useful in the case of symmetric client secret.

If the client were just using public key crypto to authenticate itself to the server, using the URI of the location of the client metadata as the client_id would suffice.

This has an advantage of smaller client_id.


2013/11/2 Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possible option without introducing further complications (other than the verification procedure is different). If the AS signs the JWT then it just needs to compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT then it needs to check with some trust anchor store or something similar whether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there are benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. Derek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<[e-mail]<mailto:[e-mail]>> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way
that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list [e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth