status assertion credential binding

the binding of the status assertion with the credential is made with the credential hash, signed within the status assertion.

in the current text, there is also the cnf.jwk claim, privinding the binding with the cryptograohic material included in the credential. this latter represent an additional binding and this require additional elements to guide the implementors in how to behave when one of the provided binding is not aligned with the credential (assertion invalidation, I would say).

At the same time, there may be cases when the related credential doesn't have any cryptographic key binding, in these cases the claim cnf.jwj doersn't have any reason to exists, therefore any reason to be considered as a mandatory claim within the status assertion payload.

The proposal of the current issue is to generalize this behaviour by saying that there might be several ways to bind a credential to a status assertion, and therefore proving this during the presentation phase.

{
    "alg": "ES256",
    "typ": "status-attestation+jwt",
    "kid": $ISSUER-JWKID
}
.
{
    "iss": "https://issuer.example.org",
    "iat": 1504699136,
    "exp": 1504700136,
    "credential_hash": $CREDENTIAL-HASH,
    "credential_hash_alg": "sha-256",
    "cnf": {
        "jwk": {...}
    }
}

peppelinux / draft-demarco-oauth-status-assertions

status assertion credential binding #40