2013/11/5 Richer, Justin P. <jric...@mitre.org> > Since the client isn't really supposed to be poking around inside of the > client_id anyway, I think that JWS is a reasonable starting place, with JWE > if you want to actively hide something inside of the client_id from the > client (and browser and other parties that see the client_id). Most of the > stuff that's tied to a client's configuration isn't that sensitive, in my > opinion. >
It may or may not. It depends, really. Switching between encrypted and just signed depending on the cases seems to be a bit of overhead, though I agree that signing is a bit easier. > > Also, there are other ways to have a symmetric client secret that's > stateless beyond packing it into the client_id here. For one, since > client_secrets are also opaque to the client, you could just issue a > client_secret that's a signed JWT in its own right (or some other signed > blob), letting the AS check the signature but the client merely presenting > it as a normal client_secret. Alternatively, you could issue a bearer > assertion and accomplish the same thing. Both of these would still need to > be communicated to the client along side its client_id, the trick is coming > up with a mechanism whereby the AS can recognize it. > That's probably more reasonable. Linking two JWT with sub claim or something like that. > > -- Justin > > > > On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakim...@gmail.com> 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 <hannes.tschofe...@gmx.net> > >> 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 >>> <hannes.tschofe...@gmx.net> 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 OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
