Reconsider PoP mechanism to get a new status attestation

[paulbastian]

PoP of Credential cnf key hould not be used, instead an api-key exchanged between wallet and Issuer.

Advantages are:

• enables claim-based bound credentials
• does not require user interaction as the PoP key may be bound to PIN/Biometrics but the api-key does not, as it is provided by the Issuer during issuance

[peppelinux]

I see the benefits @paulbastian and I believe that these should be further discussed, here some additional considerations:

1. how it would enable claim-based bound credentials?
2. this depends by impl. We connsider that the attestations are fetched when the user activate/execute the wallet, therefore asap after the local authentication

[OR13]

perhaps we say "issuer MUST authenticate the wallet", and MUST support PoP and MAY support other mechanisms, and briefly describe them?

[paulbastian]

As discussed today, Oliver proposed to use a dpop key to get this at a /status endpoint. That would enable to use Referenced Token that don't have cnf claim

[peppelinux]

@paulbastian we can do this and it is resonable, we can protect the endpoint also with DPoP using a key specialized for this purpose,

thank you

[paulbastian]

As we have integrated this PR into OpenID4VCI, you may easily share tokens/api-keys in the issuance to request new status assertions, instead of relying on the PoP mechanism. I would advise to move away from the PoP key in the Credential and use an Credential Format independent mechanism instead