Kristina

one from @awoie ``` - customer applies for VC, in-person (pre-authz) or remote (authz code) - wallet requests access_token/credential - downstream process kicks off and decision needs to be made...

also from @awoie > Would it make sense to specifically describe the following scenarios: > - high-security in-person provisioning with/without human in the loop in downstream processes > - high-security...

closing since i think the ship has sailed. changing the spec name now will cause more confusion, and I think most of the people are wrapping their head around that...

let's also make sure it is optimization and not a requirement in client attestation draft.

Proposal is to use the following structure as a DPoP JWT to attest the keys DPoP is bound to. Should we add this as an optional extension in HAIP? ```...

this is obsolete since sd-jwt vc already made iat selectively disclosable. https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#section-3.2.2.2-4 need to discuss if we want to mandate `iat` to be selectively disclosable, since sd-jwt vc spec says...

I do not remember the context of this issue anymore.

@paulbastian @c2bo @tplooker has this been resolved in IETF attestation based client assertion draft?

if the point of this PR is to recommend the usage of c_nonce in general (regardless of how the issuer provides c_nocne), the specification right now actually intends to mandate...

with the discussion in #331, the direction is to remove an option to return c_nonce from the token endpoint