Discovery - 4.2 Provider Configuration File does not specify what optional parameters the server accepts

[Nat Sakimura]

Current OpenID Provider Configuration FIle does not specify what features the server supports. For example, it does not tell whether it supports "request_uri" parameter.

Need to go over the specs to find out what optional parameter support information needs to go into.

[Michael Jones]

This makes sense. We need a concrete proposal for items to the configuration.

[Nat Sakimura]

So, the following seems to be missing from the provider configuration file.

• display_type_supported: what display type it supports
• request_uri_support: whether to support it or not
• claims_supported: what standard claims it can provide values for in general
• claims_in_id_token_support: if it supports claims in id_token
• client_registration_endpoint_auth_types_supported: array.
• Supported identifier types (public and/or pairwise)
• claim_types_supported: array. What claim types it supports (Normal/Aggregated/Distributed)

[Michael Jones]

The request_uri should be MTI

[Nat Sakimura]

Thought request param was MTI but request_uri was optional. Was it not?

[Michael Jones]

At the 22-Oct-12 working group meeting at Google, we decided that we want optional functionality to be discoverable. New parameters will need to be created to advertize this information.

Also, as discussed at the meeting, the request_uri is MTI.

[Michael Jones]

Mike will take a crack at this. Request_uri doesn't make sense. Claims_in_id_token was deleted. We'll have to look at what functionality is optional that it makes sense to discover.

[Michael Jones]

Nat will create a new proposed list of additional provider configuration features.

[Nat Sakimura]

New list:

• display_types_supported: array : what display type it supports
• std_claims_supported: what standard claims it can generally provide the values (note: all Connect idP MUST be able to understand std claims.)
• ext_claims_supported: what non-standard claims it can understand as well as provide values in general.
• client_registration_endpoint_auth_types_supported: array.
• supported_identifier_types: (public, pairwise, (and anonymous?))
• claim_types_supported: array. What claim types it supports (Normal/Aggregated/Distributed)

[Michael Jones]

Use display_types_supported.

request_uri is already mandatory.

Not comfortable making a distinction between standard claims and other claims: Should just be claims_supported - Claims that the server may be capable of providing values for.

None of these seem mandatory. Use a default rather than mandatory discovery attributes.

[Michael Jones]

Fixed #656 - Discovery - 4.2 Provider Configuration File does not specify what optional parameters the server accepts

→ <<cset 69c12b86db6a>>

[Michael Jones]

It's not clear to me what the values of the client_registration_endpoint_auth_types_supported parameter should be. Thus, I haven't added it yet.

I'm also reconsidering whether we should rename token_endpoint_auth_types_supported to token_endpoint_auth_methods_supported, per a previous request, as the name better fits the textual description. In either event the two names should be parallel when the second one is added.

[Michael Jones]

The only thing we curently support for registration authorization is OAuth Bearer. Therefore, we don't need a parameter for a single-valued item.

[Michael Jones]

Fixed #656 - Changed token_endpoint_auth_type to token_endpoint_auth_method

→ <<cset 35412a3fe2a6>>