Christian Bormann

> * this change feels quite sd-jwt specific, and I don't think it is clear why properties of the credential configuration such as `format` and `credential_definition` are defined outside of...

I think this should be moved to OpenID4VP - I don't think this belongs in HAIP?

From a layering prospective, this is very likely bound to credential formats - on the protocol level it would mainly be about being able to support such formats (and possibly...

Apparently github understood > We could specify a session transcript in Invocation via other methods {#non-dc-api-invocation} to resolve https://github.com/openid/OpenID4VP/issues/402 as "resolves 402" 😅

Agreed that reporting abuse (and also more generally speaking aggregated signals for abuse) are going to be important topics to make sure the ecosystems can grow and evolve securely. In...

> It's not clear, safe advice to the user to tell them to go ahead with a transaction that they find suspicious. In the current flows there is no DC...

> OpenID4VP removed it [here](https://github.com/openid/OpenID4VP/issues/289), in part aligning with [@marcoscaceres](https://github.com/marcoscaceres) [arguments](https://github.com/openid/OpenID4VP/issues/230#issuecomment-2306321785) on it being the responsibility of the verifier. > > However if we can enable auditability somehow (like in...

@RByers AFAIK, its currently a mix of several high-level requirements in the ARF and ETSI is in the process of creating a technical specification based on those requirements for presentation...

> I'm wondering about what this means for other systems, given that this would be only for EUDI. It'd be great if we could encourage the provision of purpose information...

> > I think at the very least we should make sure there is some form of purpose information being shared AND that information is somehow bound to that verifier...