-
assigned issue to
- changed status to open
Discovery 3.2 - Define which discovery element is mandatory
Please clarify each claims are mandatory or not. I think current draft permits any JSON objects are parsed as valid Provider Configuration Response.
Comments (8)
-
-
We may, however, want to say that if they are not configured out of band, which elements are required in what cases.
-
- changed title to Discovery 3.2 - Define which discovery element is mandatory
- edited description
-
Per the discussions at the 22-Oct-12 working group meeting at Google, this pertains to the different layers of MTI features. For OPs, there will be different sets of MTI features for "open" systems (another possible term suggested is "dynamic") and "closed" systems (other possible terms are "static", "pre-negotiated", and "out-of-band").
This is largely a subset of issue
#604(All - Create a MTI section), but is being left open until this and#604have been resolved in the specs. -
-
assigned issue to
- edited description
John believes that none of these elements are mandatory. Mike will review while writing the "Implementation Considerations" section. Some do need to be there for common profiles, like the public key.
-
assigned issue to
-
It seems to me like these elemenets are candidates for being REQUIRED: version, issuer, x509_url, id_token_signing_alg_values_supported, response_types_supported, subject_types_supported. A case could also be made for scopes_supported, claim_types_supported, and claims_supported.
Let's discuss this on the call.
-
Mike will make the first list REQUIRED and the second list RECOMMENDED
-
- changed status to resolved
Fixed
#628- Defined REQUIRED, RECOMMENDED, and OPTIONAL discovery elements→ <<cset b7942460377b>>
- Log in to comment
None are required because any of them could have been configured out of band. We should say that in the spec.