If you read the draft the redirect URI and other parameters are encoded into the JWT assertion.
What we are proposing is using an assertion/token as the client_id that assertion cannot be a bearer assertion for confidential clients, that would be inssecure. IT needs to be some sort of proof of possession assertion/token. There are several ways to do proof of possession one is including a public key and the other is encrypting a symmetric key. The option I didn't include is using some sort of key derivation mechanism, DH etc so that you don't need to encrypt if using a symmetric password. Symmetric passwords have all sorts of problems. A static assertion without PoP has similar problems with securing it in the client. For reference the sort of compromises I am concerned about are already starting to happen. http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-serious-wake-up-call-for-the-web/ John B. On Nov 4, 2013, at 2:06 PM, Phil Hunt <[email protected]> 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 > [email protected] > > On 2013-11-04, at 1:58 PM, Nat Sakimura <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
