See my reply to Justin. BTW, is not the client authentication one of the pain point for the server that we want to solve statelessly?
2013/11/5 Anthony Nadalin <[email protected]> > We need to avoid encoding secrets and authentication with client_id as > authentication is not part of our mission > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Nat Sakimura > *Sent:* Monday, November 4, 2013 1:38 PM > *To:* Hannes Tschofenig > *Cc:* [email protected] WG > *Subject:* Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 > > > > 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 <[email protected]> > > 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 > <[email protected]> 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 [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
