Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Some discussion below…

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-02-03, at 9:26 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

> So it's a tiny bit better but not sure it has captured all of what was being proposed to fix the original, still not there.
> 
> 1. The signature on the software statement should be optional 

Signatures should be REQUIRED.  Unsigned data should be passed in the normal registration request.  The point of the statement is to "lock" the registration metadata between instances.  

> 2. The software statement should be an assertion, the assertion can be whatever profiles exist, I understand the desire this to be a JWT but that is too limiting, for interop purposes this could be  as JWT assertion.

Not sure I understand the distinction here. Are you suggesting that a SAML assertion should also be acceptable?  I guess it doesn't matter as long as the servers are prepared to handle it.  

This is brand-new functionality, so I'm not sure why other assertions are important. Can you give a case where a non-JWT assertion would be beneficial?  e.g. are you thinking it might be easier to extend an existing MS signed software assertion with dyn reg metadata than create new JWT assertions?
> 3. The idea was to be able to remove the client secrets to reduce required management for secrets, we need to get away from this

I agree on this. But in IETF Vancouver there was a general disagreement around use of client_secrets.  Some of us interpret secrets as being passwords only while others are passing assertions as secrets.  I think this is where some of the debate/confusion is stemming from.

I would like to:
a.  clarify that secrets are passwords (this is not the way to pass assertions even though they may behave like passwords to a client)
b.  the use of passwords should be discouraged

As new functionality (no legacy), I would like to drop support for the use of passwords (secrets) for managing client registration profiles.
> 
> 
> 
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 28, 2014 8:05 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
> 
> 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