Hmmm. We are defining token drafts that discuss key distribution. Part of my objection is that doing a different method in reg not only overloads reg but complicates key mgmt.
Phil On 2013-08-23, at 9:16, John Bradley <ve7...@ve7jtb.com> wrote: > 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> > _______________________________________________ > 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
