Tobias Looker

> CHAPI is sufficiently secure as long as 1) the browser isn't compromised, or 2) the issuer site isn't compromised, or 3) authn.io (the CHAPI site) isn't compromised. I'll note...

> I'll note that placing the "one-time transaction ID" in the URL is not necessary, VPRs can encode it as POST data in an interact entry. That does not mean...

> Yes, and what I'm trying to find out is if we can at least start w/ a security proof for an end-to-end flow that we all agree is secure...

> Now that we've established that the https://github.com/w3c-ccg/vc-api/issues/279#issuecomment-1085175331 are secure for both web-based and native wallets... let's look at a use case where you cannot depend on the interaction URL...

> I thought there was a general understanding that the server was already assumed secure -- as it needs to be in any flow / protocol under consideration, right? Yes...

I may be missing something but this model still seems incomplete. Negotiation is a two way street, this proposal looks to have defined a way for one party to express...

> Protocol negotiation is never a two way street... either the party you are interacting with supports the features you need to continue or they don't. Hmm, I'm not following...

> @tplooker I was looking at this: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#page-9 is this the generic version of this for OIDC? @OR13 yes this is extracting the signed request object from oidc into its...

+1 a good next step is for us is to actually define what we mean by scope and clarify its relationship (or lack there of) to OAuth2.0

@mwherman2000 I would assume the client would receive "connection denied", the chairs and editors have labeled this pending close pre-migration to the new repos, please comment if you feel differently.