Re: Cross border identity use case - which did methods?

thanks manu,

>>The solution that we've found, that seems to work for everyone involved
regardless of where they fall on the topic above, is to allow for ONE
tightly controlled service description in a DID Document that specifies a
public interaction point where you can "Get more VCs...".

Sounds good to me - if we use did document service endpoints at all then
we'll follow that convention.

My answer to david's message about did:key vs jwt-uri for the trust link on
the cross border identity use case might also have some relevance - ie it
brings up questions about the anti-correlation intent of the exporter who
is creating dids.  Or more specifically, the design / implementation
principles observed by the software vendor that is selling services to the
exporter...  As you point out, there's lots of opportunity for poor use of
what is a very powerful technology.  I'm not entirely sure how to mitigate
this other than maybe more content in the implementation guide that is
focussed on these kind of correlatable identity architecture best
practices...

On Tue, 8 Mar 2022 at 11:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 3/6/22 3:14 PM, Steve Capell wrote:
> > - is that because you want to avoid any identity correlation concerns?
>
> As a general rule, yes.
>
> > That’s understandable but what if the use case is specifically to allow
> > correlation of a did to a public identity ?
>
> Warning: Controversial content follows...
>
> Sure, that's a valid use case. That said, how is a DLT-based system
> supposed
> to know the difference between a "public identity" and a "private
> identity".
> That is, who holds the liability when someone inevitably abuses the service
> description?
>
> Some lawyers I've talked to have said "the individual that wrote the
> record to
> the DLT". Other lawyers have said "Well, it's complicated -- could the DLT
> creators or non-profit that manages the code base or operations have
> prevented
> that from happening? If so, then yes, they're liable."
>
> The solution that we've found, that seems to work for everyone involved
> regardless of where they fall on the topic above, is to allow for ONE
> tightly
> controlled service description in a DID Document that specifies a public
> interaction point where you can "Get more VCs...".
>
> This might be a public website, a VC API exchange endpoint that requires
> authn, or some DIDCommv2 endpoint. The key here is that the type and URL
> are
> so tightly locked down that the possibility of any sort of PII being
> leaked is
> far lower than the "wild west" that service endpoints represent today.
>
> So, if we are to keep using service endpoints in DID Documents, the above
> might be a good strategy that balances the ecosystem requirements around
> discoverability and liability.
>
> -------------
>
> As an alternative, all the DID interactions we've found have the DID
> controller transmitting VCs in the very first interactions they have. So,
> if
> you want to know service endpoints associated w/ a DID, just ask when they
> do
> a DID Auth to log in. If that service every stops responding, just ask for
> an
> updated endpoint.
>
> -----------
>
> In any case, all that to say that there are multiple solutions to this
> problem... but I'm unsure if many people entering the ecosystem today are
> even
> aware of the problem (based on some really bad service description examples
> I've seen linked from DID Method registrations)... and that's from the
> people
> implementing DID Methods, much less the people using them!
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>

-- 
Steve Capell