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 <ve7...@ve7jtb.com> > 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 <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 > > > -- 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
