Need section on binding of profile to current user

[jandrieu]

We have no language specifying the binding of a presenter to a profile in a specific session.

There is consensus that the holder is not necessarily the subject. They may have complicated relationships to subjects in the included credentials, but there is some notion that presenting a profile MEANS that the presenter is claiming some relationship to the credentials.

Unfortunately, we have no language explaining that this is necessary for valid use of a profile.

There is no discussion about how a verifier can tell if the profile has been hijacked by a man-in-the-middle attack. Yes, the profile is signed. By someone claiming the assertions in the profile, e.g., "I am over 21" or "Maria Hernandez is my mother, here is my birth certificate. I am Manuel Hernandez." So we can accept that the controller of the keys is asserting those claims. But how do we know the controller of the keys is the end user of the current session, aka the Presenter?

This is why I have always felt that proving holder==subject is an unsolved problem. If it is our intention that the profile MUST be bound to a session identifier and that such binding MEANS the current end-user asserts the claims in the profile, we need to be explicit about that.

Specifying how such binding occurs is beyond the scope of the current specification. However, specifying whether or not such binding is necessary is.

[dlongley]

This could be done by including a Token Binding ID in the proof on the Profile. I'm not sure if there's anything for us to specify at the data model layer -- other than perhaps a mention of such techniques.

[dlongley]

I suppose a DID-AuthN credential could be one where you assert that did:method123 has a session:

{
  "id": "<some credential ID>",
  "type": ["VerifiableCredential", "SessionCredential"],
  "claim": {
    "id": "did:method:123",
    "session": {
      "id": "<identifier for session as given by the verifier/relying party>",
      "tokenBindingId": "<token binding ID for the session>"
    },
    "verifiableCredential": [{ /*... optional other VCs */ }]
  },
  "proof": [{/* ... */}]
}

For the case where a token binding ID is not available:

```js
{
  "id": "<some credential ID>",
  "type": ["VerifiableCredential", "SessionCredential"],
  "claim": {
    "id": "did:method:123",
    "session": "<identifier for session as given by the verifier/relying party>",
    "verifiableCredential": [{ /*... optional other VCs */ }]
  },
  "proof": [{/* ... */}]
}

[David-Chadwick]

Whilst Jo is correct, I do not think this is an issue for the data model, but rather for the protocol between the holder and the verifier. In other words, it is out of scope of the current standard and in scope for the protocol standard that will follow on.

@dlongley I agree that IETF token binding offers a solution to this.

[msporny]

F2F discussion resulted in agreeing to produce a PR that explains how to bind a profile to a particular session using a proof (such as signing the domain or token binding) and how a holder may not always be the presenter.

[msporny]

@dlongley I agree that IETF token binding offers a solution to this.

... and a some sneaky correlation concerns, but those are no different than use of verifiable credentials alongside session cookies today.

[David-Chadwick]

@msporny You seem to have introduced the new concept of presenter which is not currently defined in the latest data model document (and is only mentioned once in a note). If we are to have the new role of presenter then the data model document needs a significant revision to describe this new role and how the VC lifecycle relates to all 3 roles of subject, holder and presenter. Otherwise I suggest you drop the concept of presenter (at least in v1 of VCs)

[prowley]

A public key for the claim instance generated by the holder, along with a signature, then signed by the Issuer is a nonce away to providing assurance that the presenter was issued the claim. The data model is then transport independent while having this dimension of verifiability which is currently absent (and imho required to move beyond bearer tokens). Pushing this to the transport layer will likely result in a hodge-podge of solutions that are not inter-operable - you've already started that process in this thread. If a claim is to be truly verifiable in all dimensions the data model must support the verification and the mechanism must be independent of transport or we'll be paying for that for a long, long time.

[dlongley]

@prowley,

A public key for the claim instance generated by the holder, along with a signature, then signed by the Issuer is a nonce away to providing assurance that the presenter was issued the claim.

This sounds like it would cause the phone home problem.