Phil @independentid www.independentid.com phil.h...@oracle.com
On 2013-11-01, at 1:17 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > Hi Phil, > > thanks for the quick response. > > > Am 01.11.13 20:54, schrieb Phil Hunt: >> See below... Phil >> >> @independentid www.independentid.com phil.h...@oracle.com >> >> On 2013-11-01, at 12:13 PM, Hannes Tschofenig >> <hannes.tschofe...@gmx.net> wrote: >> >>> Hi Phil, Hi Tony, Hi all, >>> >>> regarding this document I believe there are the following questions >>> the group may want to think about: >>> >>> a) Is the lifecycle of software development (Figure 1) common >>> accross several companies? >> >> We are trying to be generic. What we are trying to do is take the old >> model where a developer would register with a Facebook, a Google, >> whatever and apply it to what happens to open source API and >> commercial API scenarios where software is deployed in many locations >> (not just a single cloud provider). > > Certainly makes sense. I am just saying that it would be good if there are > others in the group who say that the described model lines up with their > practices. You never know but their practices may actually be different. Hmmm…. not sure what granularity you are after. I am just describing what is essentially a "federated" model for registration that works for developers who have no prior relationship with the service providers that deploy a particular API. Nothing more. One way to look at this is that Software Statements preserve the current methodology of the client developer registering with the developer registration service for an API -- usually that would be the organization that controls/revises/updates the API definition. In commercial APIs that would be the vendor, in open APIs, it would be the consortium or the open source project. In OpenID Connect for example, it could be the OIDF or someone like the OIX since OIX is helping to vet/whitelist IDPs. Finally, if no organization is available to provide the developer software statement, the developer can always self-assert. In a sense this becomes similar to dyn reg now. Except with one major difference. All copies of the developer's client will still use the same assertion and the registration profile is "locked". You could even go to per instance assertions where the developer could decide to have the client generate on the fly if their use case really does demand completely different registration per client instance -- I've yet to see a valid use case, but this would still be possible. IOW -- this is no different from other federation models where AS service providers decide to trust different assertion "roots" or specific assertions as needed. A well worn model. ===> Any lifecycle model is possible! > >>> >>> b) The document defines a number of attributes. Are those >>> attributes also used in other deployments? Is their semantic >>> clearly defined so that meaningful actions can be taken when >>> receiving those? >> >> The attributes come from Dynamic Registration. Only thing new here >> is software_id and software_version. > > I didn't realize that. Maybe that's worthwhile to highlight. > > So, the question would then be to the group whether the two newly defined > attributes are sufficient and well-defined. The description was good for me. My understanding is that dyn reg has these attributes as well (so they are no longer new). It may be that software statement's attributes need to be updated to reflect the current dyn reg phrasing. > >>> >>> c) Is the proposed approach for conveying the software statement >>> acceptable for the group? (currently the information is conveyed as >>> a bearer token encoded as JWT). >> >> John Bradley's JWT token is similar, but I think they have different >> characteristics in the way they are used. I'd like to here John >> present this at the meeting before I attempt to try and compare them. >> This is something I'd like to work on together. > > Thanks; that might be useful. I personally don't have a preference here but > getting feedback from the group would be good. > > >>> >>> What would be good to have is two things: >>> >>> * Examples >>> >>> * Text that describes what decisions can be made by the >>> introduction of the software assertions. This text could go into >>> the introduction to provide a motivation about why to use it. >> >> I am open to a lot of change her. If anything, my feeling is that if >> anything we should cut the drafts back down to the raw normative >> text. It is my feeling there is too much explanatory text that >> drives the perception that the proposal is complex. Yet this boils >> down to 3 methods: >> >> Static - do what you are doing now if that works. Dynamic - Swap a >> software statement (shared by all instances of the same app) for an >> individual client assertion (assertion swap) Transient - just pass >> your software_id (or maybe it should be software statement) as you >> client_id > > I like that short summary. That should be something for the intro > > Ciao > Hannes > >> >>> >>> 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
