Top level request object structure should be fully defined by protocol identifier

[timcappalli]

Some protocols may have different modes / types for requests, such as signing the entire request object. This changes the top level structure of the request object in the Digital Credentials API.

OID4VP is a protocol which supports both unsigned and signed requests. For example:

OID4VP unsigned request

const credential = await navigator.credentials.get({
  digital: {
    requests: [{
      protocol: "openid4vp",
      data: {
        "client_id": "digital-credentials.dev",
        "client_id_scheme": "web-origin",
        "response_type": "vp_token",
        "nonce": "m6wM5ykCK6UnsFfDCV8-F9pWNv-vZ92JFHYc9R2w0ms=",
        "presentation_definition": {}
      }
    }]
  }
});

OID4VP signed request (proposed, not final)

const credential = await navigator.credentials.get({
  digital: {
    providers: [{
      protocol: "openid4vp",
      data: {
        "payload": "eyAiaXNzIjogImh0dHBzOi8...NzY4Mzc4MzYiIF0gfQ",
        "signatures": [
          {
            "protected": "eyJhbGciOiJFUzI1NiJ9",
            "header": {
              "client_id": "987647789",
              "client_id_scheme": "x509_san_dns"
            },
            "signature": "PFwem0Ajp2Sag...T2z784h8TQqgTR9tXcif0jw"
          },
          {
            "protected": "eyJhbGciOiJFUzI1NiJ9",
            "header": {
              "client_id": "https://rp.federation.eu",
              "client_id_scheme": "entity_id"
            },
            "signature": "irgtXbJGwE2wN4Lc...2TvUodsE0vaC-NXpB9G39cMXZ9A"
          }
        ]
      }
    }
    ]
  }
});

So for these examples, the standard unsigned OID4VP request could just use the protocol name openid4vp-v1, whereas the signed request would use openid4vp-signed-v1 (or do we always want to be explicit and not have a default mode, e.g. openid4vp-unsigned-v1?)

This would be instead of introducing another top level property to the API (such as requestType or requestMode).

The registry in the spec would point to the specific portion of the protocol specification which defines that mode/type/behavior.

[OR13]

It seems like you are considering specifying request as being a JSON parsed version of https://www.iana.org/assignments/media-types/application/jose+json

Not sure if you need agility here (for example to support more compact binary requests), but you might consider generalizing the signed request variant to support media types.

request_content_type: application/jose+json or application/cose or application/eat+cwt, etc...
request_content: Uint8Array

perhaps for protocol: "openid4vp", you know this will only ever be JOSE / JSON... so this comment is not relevant to that protocol.

If you are considering both signed and unsigned structured data, you might find this draft relevant to your design: https://datatracker.ietf.org/doc/draft-ietf-rats-eat-media-type/

[bc-pi]

As mentioned on yesterday's call - at this level, I'm in favor of continuing to treat OpenID4VP as one "protocol" and using a single protocol identifier for it.