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
