Verifiable Presentations do not work outside of their own protocol.

[Tom Jones]

This is sort-of a follow up to Tony’s concerns.

It may be that a work-around exists, but if so that needs to be explicitly documented. The following is a question i had on Slack with Orie and Tobias. It seems that VPs, on their own, do not prevent replay. They depend on the outer protocol. I hope that some one can create documentation on their use in SIOP that proves me (and Tony) wrong, but i haven’t been convinced. It seems to be an inherent defect in the VP data format. They are only valid within the protocol and not on their own.

(aside comment - we could fix that in SIOP by just adding an element to the VP)

Tobias posted a VP exchange & I responded to that.
Tom Jones  1 hour ago
I am not intimately familiar with the format, but since I don't see an aud or nonce, I don't understand how you propose to prevent replays.

Orie Steele (Transmute)  9 minutes ago
domain and challenge in the W3C VC Data Model  address this exact concern (edited) 

Orie Steele (Transmute)  8 minutes ago
https://www.w3.org/TR/vc-data-model/#example-2-a-simple-example-of-a-verifiable-presentation

w3.orgVerifiable Credentials Data Model 1.0Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

Tom Jones  < 1 minute ago
@Orie Steele (Transmute) @Kristina (MSFT/MyData/OIDF) That might be a problem with SIOP.  I think we need to get together on this.

[Dmitri Zagidulin]

+1 to what Orie said. That’s exactly the correspondence, in VPs.

aud → VP’s domain property

nonce → VP’s challenge property.

[Tom Jones]

Well that sounds to me like the VP cannot ever be embedded in anything then. It only ever fits its own protocol.

[Kristina Yasuda]

VP can be embedded in any transport protocol, we just need to specify in the transport protocol which property there maps to which VP’s property. There should be a text about it in OIDC4 VP draft. @Torsten Lodderstedt

[Torsten Lodderstedt]

I think Dmitri is completely right. The VPs shall be protected from replay by binding them to the transaction (nonce) and the intended audience (client_id).

For LD Proofs, this means

• “domain” set to “client_id” of the requesting client
• “challenge” set to “nonce” of the request

For JWT-based VPs, it’s a 101 mapping.

‌

[Oliver Terbu]

Proposal:

To prevent replay attacks, verifiable presentation cointainer objects MUST use client_id and if provided nonce from the Authentication Request. The values are passed through unmodified from the Authentication Request to the verifiable presentations. Note, these values MAY be represented in different claims according to the selected proof format denated by the format claim in the verifiable presentation container.

Here is a non-normative example for format='jwt_vp' (only relevant part):

{
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "aud": "s6BhdRkqt3",
  "nonce": "343s$FSFDa-",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "vp": {
    "@context": [
      "<https://www.w3.org/2018/credentials/v1",>
      "<https://www.w3.org/2018/credentials/examples/v1">
    ],
    "type": ["VerifiablePresentation"],

    "verifiableCredential": [""]
  }
}

In the example above, nonce is included as the nonce and client_id as the aud value in the proof of the verifiable presentation.

Here is a non-normative example for format='ldp_vp' (only relevant part):

{
  "@context": [ ... ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [ ... ],
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",    
    "challenge": "n-0S6_WzA2Mj",
    "domain": "s6BhdRkqt3",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

In the example above, nonce is included as the challenge and client_id as the domain value in the proof of the verifiable presentation.

[Tom Jones]

where is the normative statement that backs up your assertion?

[Oliver Terbu]

The language above is a proposal for a normative statement that I’d add to the OIDC Verifiable Presentation draft + non-normative examples.

[Torsten Lodderstedt]

corresponding PR #21

[Kristina Yasuda]

@tom propose to close this as PR #21 has been merged.

[Michael Jones]

Closing during the 15-Jun-21 call, since PR #21 addressed this issue.