We have that in the OIDC version where the client publishes it's public key. That is in general better from a security point of view if you believe clients can securely generate key pairs.
It is not in the IETF version because we were asked not to include authentication methods not defined in the core spec, as they were thought best to be extensions. It currently looks like the pressure is on to remove confuguration options rather than add them. I agree that client registration is a reasonable place to exchange keys and avoid having symmetric secrets, that is the preferred OIDC implementation for clients that can support it. John B. On 2013-08-23, at 4:55 AM, Antonio Sanso <asa...@adobe.com> wrote: > Hi Hannes, > > thanks a lot for your notes. > > As suggested from you guys yesterday I'd like to bring on my little point :) > (that is really orthogonal to the whole discussion). > > IMHO since the dynamic registration is still on a design phase it would be > really nice to include something that Google already implemented in order to > allow server-to-server communication [0]. > > In order to allow this, in the registration phase, there is the option to > download a private key (in order to allow the client to sign self produced > signed JWT without 'human interaction'), quoting [0] > > "During the creation of a Service Account, you will be prompted to download a > private key. Be sure to save this private key in a secure location. After the > Service Account has been created, you will also have access to the client_id > associated with the private key." > > > IMHO this is a really clever way to use OAuth and would be nice to see this > standardized and having it on the big picture. Obviously this should be just > an optional field. > > Just my 0.02 $ > > Thanks and regards > > Antonio > > [0] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > > > > On Aug 23, 2013, at 10:24 AM, Hannes Tschofenig wrote: > >> Thank you all for joining yesterday's conference call. I took some notes >> during the call. >> >> ---- Meeting Minutes ---- >> >> Participants: >> - William Kim >> - John Bradley >> - Antonio Sanso >> - Mike Jones >> - Phil Hunt >> - Justin Richer >> - Hannes Tschofenig >> - Derek Atkins >> - Amanda Anganes >> - Morteza Ansari >> - Brian Campbell >> - Thomas Hardjono >> - Prateek Mishra >> - George Fletcher >> - Tony Nadalin >> >> Minutes >> >> Justin started with a discussion about what is described in Section 1.3 >> of the protocol specification and Appendix B describes the use cases. >> >> Dynamic client registration is one way to introduce a client to an >> authorization server. >> A client is the relationship between a client piece software and a piece >> of software on the authorization server side. >> The client needs a client_id and the authorization server needs to get >> various other piece of information (such as a redirect_uri, display_name). >> >> The group then started a discussion about what the minimal amount of >> information is the authorization server needs to have. >> >> The discussion then shifted to uses cases where trust is established >> a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg >> exchange (protected registration) and the case where there is no trust >> (=open registration); the latter case would push the obligation to the >> user. >> >> There seems to be agreement (on the call) that both use cases are valid. >> >> The following examples for protected registration have been discussed: >> >> * manual page where the developer obtains a developer key and register >> there; they end up with an initial access token (in the form of an >> bearer token) >> * UMA case where there is someone who is introducing the two parties >> to each other. (Currently not described in the document) >> * Developer Automation: Who holds the client registration information? >> The developer makes the call and you get the client_id back. The client >> is not doing the dyn. registration. (This use case is described in >> Appendix B.3) >> * John's use case: >> http://www.ietf.org/mail-archive/web/oauth/current/msg12008.html >> >> Phil Hunt starts with his presentation slides, which he had distributed >> to the mailing list earlier: >> http://www.ietf.org/mail-archive/web/oauth/current/msg12007.html >> >> Phil says that the client_id does not need to be provided by the AS - it >> could be provided by the client. John says that the client_id has to be >> tied to the redirect_uri since otherwise attacks are possible. >> >> Phil says we are lacking good terminology for client, and for client >> instance. >> >> George claims that the client instance concept came up when mobile >> clients and Web clients got mixed in deployments and people wanted to >> have a way to distinguish the two since they were different in their >> ability to keep a secret. >> >> A discussion started about whether an evolution had happened regarding >> different types of clients. The client id is a proxy for some release of >> some software. Someone claimed that with dynamic client registration we >> have the ability to turn public clients back into confidential clients. >> >> Phil argues that service providers want to know the class of >> applications and the instances. A problem with a client can be a >> compromise and you want to disable it. There may also be a bug in the >> software and then one may want to disable the entire class of clients. >> >> Phil asks whether we expect that JavaScript code registers every time >> the code runs. The response was clear that this is not the expectation. >> >> Phil then goes on to explain four levels of dynamic behavior: >> >> * Client developer hardcodes the address of the authorization server >> and other information. >> * Developer may hardcode some information but the client may >> dynamically interact with the authorization server to provide additional >> information (suggested by John) >> * Confirmation information in the client software can be used to >> dertermine which server to talk to and which parameters to use >> * Client software decides at runtime who to contact and what >> information to provide >> >> Hannes stopped the discussion because we ran out of time and started a >> discussion about where we could go next. >> >> Justin said that he has not seen anything that is not supported yet. >> Tony, Phil, and Prateek say that we are trying to find the minimum >> supported information. >> >> It seems that different folks have different use cases in mind. Can this >> situation be solved with extensions? Phil claims that the current >> specification is overly complex. >> >> It is clear that we cannot have one single spec that covers all the use >> cases. >> Are we arguing which use cases are covered in the base specification? >> >> Tony suggested that only client_id and redirect_uri should be the >> supported and everything else should be dropped. >> >> Justin responded that the rest is optional anyway. >> >> Discussion started about what "optional" means. Does the authorization >> server have to implement to implement even optional components? >> >> John says that we need a new feature for adding and removing a new >> endpoint. This is a common use case and we don't want to revoke all the >> permissions when we do so. >> >> Mike says that there is some additional material needed beyond client_id >> and redirect_uri. >> John agrees. >> >> Prateek says that we need to identify a minimal subset and have >> extensions defined. >> >> Hannes will talk to Derek about the next steps. Expect another >> conference call soon. >> >> Phil will update the software assertion document. >> >> >> _______________________________________________ >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
