Oh, I should add that I disagree that it's not necessary to return the software
statement. It's a key part of the client registration information, and so
should be returned like the other client registration information actually used.
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Wednesday, February 05, 2014 6:08 PM
To: Phil Hunt; Eve Maler
Cc: [email protected] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
Thanks for your comments, Phil. I'm working on addressing them at present.
One comment confuses me. You wrote "Section 4.1 - It would be good to have an
example with a software statement and no initial access token (or both)." Yet
the last example in Section 4.1 already is such as an example (taken from
draft-hunt-oauth-client-association, actually). Was there something else that
you were thinking of?
Also, the "Deployment Organization" definition *does* describe when it and the
deployment organization are different. Where I think that the text describing
the choices for the two cases belongs is a subsection of the Use Cases
appendix. Do you want to write text about the two cases, Phi?
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Phil Hunt
Sent: Monday, February 03, 2014 12:18 PM
To: Eve Maler
Cc: [email protected] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
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.
Section 4.1
It would be good to have an example with a software statement and no initial
access token (or both).
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.
Dyn-Reg-Metadata
The metadata document looks fine. I would prefer it being included in dyn reg,
but can live with it as is.
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.
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
@independentid
www.independentid.com
[email protected]
On 2014-01-30, at 7:33 PM, Eve Maler <[email protected]> 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 <[email protected]>
> 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
>> [email protected]
>> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
