Update dynamic client registration spec to reference OAuth2 dynamic client reg

[gffletch]

In section 2.0 (Client Metadata) of the Dynamic Client Registration spec there is a statement at the end of the section that says "Additional Client Metadata parameters MAY also be used. ..."

I recommend we update this text to also reference the OAuth2 Dynamic Client Registration spec as another place where additional client metadata parameters are defined (specifically, scope and software statements).

"Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session] and OAuth 2.0 Dynamic Client Registration Protocol [https://tools.ietf.org/html/rfc7591]".

[gffletch]

We may want to specifically mention that the use of the 'scope', 'software_statement' and Initial Access Token may be of interest to implementors looking to support Dynamic Client Registration.

[Filip Skokan]

We may want to specifically mention that the use of the 'scope', 'software_statement' and Initial Access Token may be of interest to implementors looking to support Dynamic Client Registration.

Agreed.

[Michael Jones]

This is already addressed in the errata drafts. See the text referencing RFC 7591 at https://openid.net/specs/openid-connect-registration-1_0-30.html#ImplementationConsiderations .

[gffletch]

Thanks Mike! How do you feel about referencing section 8.2 in section 2.0? Something like..

For additional implementation considerations see section 8.2.

[Michael Jones]

You mean referencing section 8.2 of Registration in section 2 of Registration? That would seem to me to just be adding text but not increasing the clarity for most implementers. If they care about stateless registration they'll already be aware of 8.2. If they don't, we'd just be creating a distraction for them. Anyway, that's my view, given the information I have at present.

[gffletch]

Yes I was thinking about mentioning section 8.2 in section 2 of registration. The reason I believe this is valuable is that I suspect most developers don't read the entire spec but look for the parts they need "right now". When I was going through the doc looking for mention of software statements in the OIDC registration spec, I didn't get to section 8.2 (obviously otherwise I might not have filed this ticket :)

[Michael Jones]

I personally don't think we should go out of our way to encourage people to use features outside the spec as approved, as doing so will decrease interoperability. If people are implementing a profile that uses software statements, this will be clear in their profile document and so the extra text in Section 2 would be superfluous to them.

[gffletch]

I disagree... in that I would not consider it "best practice" to implement dynamic client registration (DCR) without software statements or scopes. I realize that at the time there wasn't the thought completion around OAuth2 Dynamic Client Registration so the OIDC version led the way. That said, if best practice would lean toward using a mix of both specs (since they aren't incompatible) then I'd rather we make it clear that doing so is allowed/encouraged.

I agree that it may "hurt" OIDC interoperability, but interoperability is only useful if what is being implemented is a good practice. I don't see many "completely open" DCR flows in production or being used in the industry. Maybe I'm looking in the wrong places:)

[Michael Jones]

I've thought about this some more since reading your comment. Consider the mission of the OpenID Foundation - to create specifications giving people control of their identity. Part of that is deploying systems in which people can use the identity provider of their choice. The Discovery and Registration specifications were written to enable exactly these kinds of deployments.

Viewed through this lens, I personally consider requiring software statements to be a bad practice, as it results in closed systems, reducing user's control over their digital identities. Yes, organizations may choose to deploy systems in ways that reduce user choice and we can't stop that, but it goes against our mission to encourage them to do so.

The errata drafts already reference RFC 7591 and mention that additional registration metadata values can be used, including software_statement. I think that's as far as we should go towards describing the possibility of using functionality beyond the OpenID specifications in deployments.

[gffletch]

Ok, let's leave it at just the reference to RFC 7591.

In regards to the larger ecosystem goal, I'm not sure the industry is even close to that point. Just as relying parties are reticent to trust any OpenID OP that shows up, OpenID OPs are reticent to allow any client to register with them (especially depending on which scopes are requested). Additionally, there are very few (if any) public apps that will dynamically register with any OpenID OP. If it is a goal of the foundation to enable such an ecosystem, then we have a lot more work to do to make such an ecosystem viable:)

[gffletch]

From a workflow perspective we can close this issue.