Regarding glossary, I can take a shot unless Mike wants to first. Phil
@independentid www.independentid.com phil.h...@oracle.com On 2014-02-03, at 6:36 PM, Justin Richer <jric...@mitre.org> wrote: > I still haven't done a deeply comprehensive read of the three posted drafts, > but I'm pretty happy with what I've read so far. Implementors should note > that if you merge all three drafts together you get functionality that is > compatible with -14 (plus software statements). > > Some comments inline to respond to Phil's review: > > On Feb 3, 2014, at 3:17 PM, Phil Hunt <phil.h...@oracle.com> wrote: > >> I am generally in agreement on the new drafts. Thanks Mike! >> >> Here are some comments: >> >> In the software statement section 3: >>> If the authorization server determines that the claims in a software >>> statement uniquely identify a piece of software, the same Client ID >>> value MAY be returned for all dynamic registrations using that >>> software statement. >>> >>> In some cases, authorization servers MAY choose to accept a software >>> statement value directly as a Client ID in an authorization request, >>> without a prior dynamic client registration having been performed. >>> The circumstances under which an authorization server would do so, >>> and the specific software statement characteristics required in this >>> case, are beyond the scope of this specification. >>> >> >> We should call out that the server MAY also issue per instance client_id's >> (the opposite of the first quoted paragraph above) if it chooses to use >> client_id as an instance identifier (the software_id identifies what clients >> are based on the same software). I think this will be the typical use case. >> Not sure whether the first paragraph should be re-written, or a new one >> added. > > Agree that if we're going to call out the exception we should state the rule. > This might be better handled in text about the client_id itself, but it > should be referenced here as well. Perhaps with something simple along the > lines of "An Authorization Server will generally issue a new client id for > each dynamic registration. However, if the authorization server determines > [...]" > >> >> Section 4.1 >> It would be good to have an example with a software statement and no initial >> access token (or both). > > Perhaps we should move all but the most basic examples to a more > comprehensive appendix? Now that the matrix of optionality is increased we > should definitely *have* the examples of the different cases, but there's > probably not a good reason to put them all inline. > >> >> Section 5.1 >> Should we also say that is not necessary to return the software statement. >> Note: the server should return the meta data that was obtained from the >> statement. > > Agree to both -- good catches. Though I think the server MAY return the > statement if it wants to, not really any harm in it. > >> >> Dyn-Reg-Metadata >> The metadata document looks fine. I would prefer it being included in dyn >> reg, but can live with it as is. > > I agree with Phil on this one. I would also rather it be inside the main > document but with the components marked as optional (as they are in -14), but > if there's a strong sentiment to keep them separate then this is not a hill I > care to die on. > >> >> Dyn-Reg-Management >> I'd like to discuss this more in London. I think a SCIM based management >> API may be simpler to write up and can leverage the features of SCIM without >> having to redefine them in a new API. Still, SCIM is a way off from >> approval -- so I understand the need to move forward now. Is experimental >> the right way to go? I am not sure. > > I'm still in favor of a simple RESTful API for this, non-SCIM. SCIM brings in > a lot of weight with it (schemas and object types, data models, etc). I > completely understand that if you're doing SCIM then it's simpler to have all > of your object-management APIs be SCIM-based. But it's important to realize > that there are literally millions of non-SCIM RESTful object provisioning and > management APIs out there as well, and they work fine. That said, if we can > make sure (as best as we can) to not step on any SCIM namespace bits that > would make it difficult to include the OAuth Dynamic Registration Client > Model (tm) as a SCIM object as part of a future SCIM extension, we should try > to do that now. That is to say, I think the best way forward is to define our > own simple RESTful API but leave the door wide open for the SCIM group to > make their own SCIM-based API to use at a future date as they see fit. > >> >> Glossary >> The terms Software API Publisher and Software API Deployer are defined but >> never used, Specifically the text describing the issue of when these are two >> distinct entities is missing. When publisher and deployer are the same (eg. >> as with Facebook), the dynamic registration need is minimal since a >> client_id can be issued from a single domain. When publisher and deployer >> are different, such as with OpenID Connect, SCIM, then the client developer >> cannot pre-register for a client_id at development time. >> >> The software statement is an optional mechanism that enables developers to >> pre-registrater to obtain a signed statement (instead of a client_id) so >> that API deployers can recognize the pre-registration relationship with the >> publisher. Of course, software statements are optional if you don't need to >> be able to recognize what the client is. (apologies if I have not phrased >> the issue optimally) >> >> Maybe if we can put in a couple of paragraphs explaining this distinction? > > Phil, I think you're in the best position to get these definitions correct, > so any text that you could contribute would be a good addition here. > >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> On 2014-01-30, at 7:33 PM, Eve Maler <e...@xmlgrrl.com> wrote: >> >>> Hi Hannes-- The UMA Core spec currently points directly to the basic >>> dynamic client reg doc with MAY statements, and is agnostic as to usage of >>> the higher-order functions. (These turn into optional interop feature >>> tests.) So I think it's fair to say that the split has no structural >>> problems from an UMA perspective. >>> >>> Eve >>> >>> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> >>> wrote: >>> >>>> Hi all, >>>> >>>> as you have seen from the meeting minutes of our recent status chat it >>>> is time to proceed with the dynamic client registration work. >>>> >>>> The earlier version of the dynamic client registration document was >>>> split into three parts, namely >>>> (1) the current working group draft containing only minimal >>>> functionality, >>>> (2) a document describing meta-data, and >>>> (3) a document containing management functionality. >>>> >>>> This change was made as outcome of the discussions we had more or less >>>> over the last 9 months. >>>> >>>> The latter two documents are individual submissions at this point. New >>>> content is not available with the recent changes. So, it is one of those >>>> document management issues. >>>> >>>> I had a chat with Stephen about WG adoption of the two individual >>>> submissions as WG items. It was OK for him given that it is a purely >>>> document management action. However, before we turn the documents into >>>> WG items we need your feedback on a number of issues: >>>> >>>> 1) Do you have concerns with the document split? Do you object or >>>> approve it? >>>> 2) Is the separation of the functionality into these three documents >>>> correct? Should the line be drawn differently? >>>> 3) Do you have comments on the documents overall? >>>> >>>> We would like to receive high-level feedback within a week. We are also >>>> eager to hear from implementers and other projects using the dynamic >>>> client registration work (such as OpenID Connect, UMA, the >>>> BlueButton/GreenButton Initiative, etc.) >>>> >>>> For more detailed reviews please wait till we re-do the WGLC (which we >>>> plan to do soon). We have to restart the WGLC due to discussions last >>>> years and the resulting changes to these documents. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> PS: Derek and I also think that Phil should become co-auhor of these >>>> documents for his contributions. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> Eve Maler http://www.xmlgrrl.com/blog >>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>> >>> _______________________________________________ >>> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
