Re: How much is it reasonable to generalize from the TruAge implementation?

This thread has already raised significant issues with capability detection
and there may be enough agreement to drive toward a consensus on how to
move forward. I see a couple of high importance cases to consider toward a
consensus:

1 - Many VC uses don't need to prevent duplication of a VC and therefore
could avoid capability detection because the holder would be free to move
the VC to whatever wallets or agents they want.

2 - Many VC uses don't suffer from calling home because they're public.
This includes most professional credentials and most high-value credentials
when used by law enforcement. It's only the use of high value credentials
outside of law enforcement that poses a calling home issue.

3 - Many correlation problems have little to do with the VCs themselves and
can be handled through mediation. VC subjects can choose their mediators
the way we choose a VPN, or ApplePay or Hide My email from Apple. In some
cases, like TruAge, the "mediator" is not freely chosen by the subject but
the handling of the VC is done by a dedicated app rather than a general
purpose wallet. Can we list the top three use-cases that realistically do
not allow correlation in spite of payment, shipping, KYC, or notification
components regardless of what VCs are also involved?

4 - How many VCs will be used by delegates of the subject for convenience
and cost? Are we actively trying to prevent delegation by default? If so,
then what are the top three cases where delegation absolutely cannot be
allowed?

5 - How will we solve the most important privacy problem of all, which is
the right to be left alone by default? As subjects, we want to be anonymous
by default. We would pay cash for small transactions that are below the KYC
limits and we would use credit cards we choose as payment mediators in
order to benefit from various fraud protections? Will there be a rise of
logistics mediators as well to guarantee that our shipping information is
not used to correlate us?

My guess, after working on digital identity use cases as much as anyone, is
that after we answer the five questions above, we will be left with some
problems around online uses that will benefit from wallet certification.
Even then, it's not clear that capabilities will be a useful alternative to
vendor certification or trust marks.

Adrian

On Tue, Nov 14, 2023 at 9:04 PM <steve.e.magennis@gmail.com> wrote:

> > I think, if we do our work right, wallets should be considered trustless.
>
> This thought has been bugging me all day. If someone drops a credential in
> my lap - regardless of where it came from or how it got to me - I should be
> able to convince myself of the accuracy of the entity that issued the
> credential and that what I now have in my possession has not been
> adulterated in transit. That said, in practice unless we expect verifiers
> to get down to the byte level to make trust decisions, the code and devices
> that abstract the low level cryptographic detail and interchange protocols
> needs to exist in some sort of trust framework. That framework could be a
> technically recursive trust framework, but I think it could just as easily
> be something like a trust mark, a brand name or even the existence of
> reasonable legal recourse to make a party whole (to the extent possible) if
> damage is done. Presumably, there would be some set of standards and
> compliance backing up any of these trust frameworks (that themselves would
> be subject to the question about recursive trust - but in large measure as
> end consumers we tend to look to trust marks to provide enough assurance so
> that we don't have to do a lot of due diligence upstream of them).
> Arguably, in order of the importance of trusted code and devices it may be
> that verifiers warrant the greatest consideration, followed by holders then
> issuers.  The argument being that verifiers have the least involvement in
> the content and transit of a credential and therefore the greatest exposure
> to using the information.
> $0.02
>
>
>
> -----Original Message-----
> From: John, Anil <anil.john@hq.dhs.gov>
> Sent: Tuesday, November 14, 2023 11:09 AM
> To: W3C Credentials Community Group <public-credentials@w3.org>
> Subject: RE: How much is it reasonable to generalize from the TruAge
> implementation?
>
> > I think, if we do our work right, wallets should be considered trustless.
> > Issuers and verifiers should be able to have confidence that they *do
> not need to trust wallets* to get trust in the VCs and their associated
> presentations.
>
> Interesting. I need to think about this a lot more.
>
> It reminds me of an approach that implements capabilities that ensure that
> opaque data blobs (while traveling or at rest) be self-protecting
> regardless of where it is physically located.
>
> Best Regards,
>
> Anil
>
> Email Response Time – 24 Hours or more; I sometimes send emails outside of
> business days/times because it works for me; please do not feel any
> obligation to reply to them outside of your normal working patterns.
>
>
>
>
>