Should `subject_syntax_types_supported` be an array of strings?

[frankhinek]

Context

The current KCC doc includes the following:

https://github.com/TBD54566975/known-customer-credential/blob/eabbb0df542d952cbbf41fc09c7f05c9aff8190a/README.md?plain=1#L290

which defines subject_syntax_types_supported as a "Space separated list of DID methods."

The linked SIOPv2 spec states:

• subject_syntax_types_supported
  • REQUIRED. A JSON array of strings representing URI scheme identifiers and optionally method names of supported Subject Syntax Types defined in Section 8. When Subject Syntax Type is JWK Thumbprint, a valid value is urn:ietf:params:oauth:jwk-thumbprint defined in [RFC9278]. When Subject Syntax Type is Decentralized Identifier, valid values MUST be a did: prefix followed by a supported DID method without a : suffix. For example, support for the DID method with a method-name "example" would be represented by did:example. Support for all DID methods is indicated by sending did without any method-name.

Proposal

Change the subject_syntax_types_supported to be an array of strings.

Additional Supporting Material

A variety of examples in the SIOPv2 spec such as:

{
  "subject_syntax_types_supported": [
    "urn:ietf:params:oauth:jwk-thumbprint",
    "did:example",
    "did:key"
  ]
}

The use of an array of strings seems to be consistently implemented by other organizations / libraries:

EBSI Conformance - Authorisation Server discovery metadata

Screenshot


EBSI Conformance Guide - Example

{
  "issuer": "https://api-conformance.ebsi.eu/conformance/v3/auth-mock",
  "authorization_endpoint": "https://api-conformance.ebsi.eu/conformance/v3/auth-mock/authorize",
  "token_endpoint": "https://api-conformance.ebsi.eu/conformance/v3/auth-mock/token",
  "jwks_uri": "https://api-conformance.ebsi.eu/conformance/v3/auth-mock/jwks",
  "scopes_supported": ["openid"],
  "response_types_supported": ["code", "vp_token", "id_token"],
  "response_modes_supported": ["query"],
  "grant_types_supported": ["authorization_code"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["ES256"],
  "request_object_signing_alg_values_supported": ["ES256"],
  "request_parameter_supported": true,
  "request_uri_parameter_supported": true,
  "token_endpoint_auth_methods_supported": ["private_key_jwt"],
  "vp_formats_supported": {
    "jwt_vp": {
      "alg_values_supported": ["ES256"]
    },
    "jwt_vc": {
      "alg_values_supported": ["ES256"]
    }
  },
  "subject_syntax_types_supported": ["did:key", "did:ebsi"],
  "subject_trust_frameworks_supported": ["ebsi"],
  "id_token_types_supported": [
    "subject_signed_id_token",
    "attester_signed_id_token"
  ]
}

Microsoft Entra Wallet Library

Code excerpt

    @SerialName("subject_syntax_types_supported")
    val subjectSyntaxTypesSupported: List<String> = emptyList(),

Open Wallet Foundation - Credo OpenID4VC Module

Code excerpt

        subject_syntax_types_supported: supportedDidMethods.map((m) => `did:${m}`),

[Sphereon SIOP-OID4VP Library]()

• Authorization Response schema
• RP Registration Metadata schema

[decentralgabe]

I agree with supporting an array, and I will open an issue on the SIOP spec

[KendallWeihe]

Agreed with subject_syntax_types_supported being an array of strings, seems like a bug in our spec. @decentralgabe the SIOP spec appears correct, it's ours which is incorrect, or am I missing something?

[decentralgabe]

@KendallWeihe correct

[tomdaffurn]

Agree, it's a bug in this spec. We should fix