define sessiontranscript for mdoc profile over DC API

[jogu]

          From a security perspective, what kind of attacks are mitigated by inclusion of the clientID in the sessiontranscript?

Inclusion of the clientId also has other issues, like which value is used if there are multiple signatures, or if the wallet ignores RP authentication.

Originally posted by @martijnharing in #122 (comment)

[awoie]

The current proposal adds all parameters in plaintext to the SessionTranscript which could introduce privacy issues with specific architectures. Especially, if the actual signing/macing operation is performed by an external or remote device, the current definition of the SessionTranscript would leak a lot of context information to the external or remote device. To mitigate this, the only hashes should be included in the SessionTranscript.

Copying the proposal I made in the other PR #122 to mitigate this concern.

Proposal

OID4VPDCAPIHandover = [
  "OID4VPDCAPIHandover", ; A fixed identifier for this handover type
  OID4VPDCAPIHandoverInfoHash ; Integrity hash of OID4VPDCAPIHandoverInfo
]
clientId = tstr  ; UTF-8 encoded string representing the client ID
origin = tstr    ; UTF-8 encoded string representing the origin
nonce = tstr     ; UTF-8 encoded string representing the nonce
OID4VPDCAPIHandoverInfo = [ clientId, origin, nonce ] ; Array containing handover parameters
OID4VPDCAPIHandoverInfoHash = tstr  ; UTF-8 encoded string for the integrity hash of OID4VPDCAPIHandoverInfo

OID4VPDCAPIHandover parameters:

• The first element MUST be the fixed UTF-8 encoded string "OID4VPDCAPIHandover". This serves as a unique identifier for the handover structure to prevent misinterpretation or confusion.
• The second element MUST be the OID4VPDCAPIHandoverInfoHash encoded as a UTF-8 string representing the integrity hash of the OID4VPDCAPIHandoverInfo array. The value of OID4VPDCAPIHandoverInfoHash MUST comply with the W3C Subresource integrity format as defined in [!W3C.SRI] (see below), e.g., sha256-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO.
• client_id and nonce values are UTF-8 encoded strings provided in the Authorization Request from the Verifier.
• origin is a UTF-8 encoded string representing the origin of the Verifier. The value for origin MUST be obtained from the web platform or app platform being used.

Additional References

<reference anchor="W3C.SRI" target="https://www.w3.org/TR/SRI/">
    <front>
        <author initials="D." surname="Akhawe" fullname="Devdatta Akhawe">
            <organization>
                <organizationName>Dropbox, Inc.</organizationName>
            </organization>
        </author>
        <author initials="F." surname="Braun" fullname="Frederik Braun">
            <organization>
                <organizationName>Mozilla</organizationName>
            </organization>
        </author>
        <author initials="F." surname="Marier" fullname="François Marier">
            <organization>
                <organizationName>Mozilla</organizationName>
            </organization>
        </author>
        <author initials="J." surname="Weinberger" fullname="Joel Weinberger">
            <organization>
                <organizationName>Google, Inc.</organizationName>
            </organization>
        </author>
        <title>Subresource Integrity</title>
        <date day="23" month="June" year="2016"/>
    </front>
</reference>

[awoie]

          From a security perspective, what kind of attacks are mitigated by inclusion of the clientID in the sessiontranscript?

Inclusion of the clientId also has other issues, like which value is used if there are multiple signatures, or if the wallet ignores RP authentication.

Originally posted by @martijnharing in #122 (comment)

IMO, it is needed to include client_id in the SessionTranscript for the same reasons client_id is included in SD-JWT VC KB-JWT aud.

[Sakurann]

WG call:

• agreed to hash the parameters (also parity with annex B in 18013-7).
• agreed to define this overall structure in OID4VP. and define a specific hash algorithm (or anything else specific) in HAIP.
• agreed to keep client_id. multiple client_ids can be operating on the same origin.
• agreed to keep origin.
• when request is unsigned, client_id is derived from origin
• add explanation why each parameter is added: nonce is for session binding, origin is for MITM protection, client_id is for audience binding, etc.
• changes agreed here affect KB JWT content too: adding "origin" parameter to KB JWT.
• big motivation to keep both origin and client_id is keeping the consistency between structure the same between signed and unisgned requests. For a signed request the verifier origin check is somewhat redundant if everything is working correctly (ie wallet has done the check).