Verifiable Presentation Clarification

I am confused by the verifiable presentation API and process.

The README here states you create a VP by passing in the issuer DID, which is used to create a signed JWT.

This seems wrong to me. The issuer uses their EthrDID to sign the VC, they then give that to the holder. The holder does not or at least should not, have to know the issuers keys to create a VP. They may want to use the keys associated with the subject of the credential to sign the VP. Is this just a mistake in the README?

Should it be

    let vpPayload = {
        vp: {
            '@context': ['https://www.w3.org/2018/credentials/v1'],
            type: ['VerifiablePresentation'],
            verifiableCredential: [vcJWT]
        }
    }

    vpJWT = await didJWT.createVerifiablePresentationJwt(vpPayload, subject)

Also, this library includes no API for liveness through a challenge-sign-response type flow that would protect against replay’s. In effect signing a VP seems pretty pointless without this. I could have got this signed presentation object from my friend last week, or by listening on the wire last year.

Quite possibly I am missing something here, but by going through the README and setting up a basic example that is my interpretation. Is this just out of scope and left to an implementor to handle protection against replay?

Thanks

[wip-abramson]

Ah okay so to implement this I would create a vp like:

    let vpPayload = {
        vp: {
            '@context': ['https://www.w3.org/2018/credentials/v1'],
            type: ['VerifiablePresentation'],
            verifiableCredential: [vcJWT]
        }
        nonce: "123454"
        aud: "www.example.com"
    }

And then sign it.

[awoie]

I’d say…

• nonce <-> challenge
• aud<-> domain

Note, we cannot use challenge and domain in the JWT itself as they are not registered with IANA.