> Gareth,
> 
> On the scope line in your reply to Yuan - that it is out of scope of
> the draft why a verifier would trust claims added by the holder or
> delegate holder - I think that boundary is right for a format
> document, and I want to suggest that what sits outside it is two
> questions rather than one.
> 
> Your payment example separates them cleanly. The merchant trusts the
> presenter is the legitimate holder because the initial issuer
> provisioned into a trustworthy wallet. Key binding carries that, and
> it is in scope. The added claims specifying how the card may be used
> are a different matter: the holder is authoritative over them by role,
> but authority over a claim and a human having approved this particular
> delegation are not the same fact. A compromised or steered wallet
> holding the same key produces an artifact that is valid under every
> check the format defines. Nothing in the format is wrong there - the
> question was never asked of it.
> 
> So the out-of-scope region contains at least:
> 
>   who may add claims - answered by key binding, in scope
>   whether a human approved these specific added claims - not answered
>   by key binding, and not answerable at the format layer
> 
> I raise it because the second one is where the delegation drafts,
> including this one, are converging from different directions without
> naming the same thing. Frederik pointed at your draft on the DTR
> thread as sharing the revocation-distribution problem, which is the
> same question at withdrawal time rather than issuance time: once a
> delegation is issued, the party who needs to withdraw it is the human,
> and the human is the party least able to host anything a verifier can
> query.
> 
> I am not proposing a change to the draft and I do not think either
> question belongs in a format specification. But if the format is going
> to be used for agentic delegation, a verifier will eventually need
> somewhere to look for the answer, and at the moment there is no such
> place in any of the drafts I have read. I have written the
> requirements up without a mechanism, if it is useful as a reference
> point rather than a proposal:
> 
> https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/
> 
> One question, which is the reason I am writing rather than only
> reading. You mention AP2 and Verifiable Intent, now with FIDO. Does
> that work carry a human-approval artifact distinct from the key
> binding, or is holder authority the whole of it there as well? If it
> carries one, that is the closest existing answer to the second
> question above and I would like to read it properly before saying
> anything further about the gap.
> 
> Mohamad Khalil-Yossif



_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to