- From: Alan Karp <alanhkarp@gmail.com>
- Date: Tue, 31 Dec 2024 10:18:31 -0800
- To: Daniel Hardman <daniel.hardman@gmail.com>
- Cc: Merul Dhiman <me@merul.org>, "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>, Kishore Rajasekharuni <kishore.rajasekharuni@jukshio.com>, "public-credentials (public-credentials@w3.org)" <public-credentials@w3.org>
- Message-ID: <CANpA1Z0ZmTCh_aEPW1S=10m5kvkztqL=Zq1VYNhe41HQPu=9=Q@mail.gmail.com>
Daniel's thinking is exactly why we believed showing the opaque identifier at that point in the user's workflow made sense. After our users' complaints, we thought about it and realized there was a security issue we had overlooked. A petname makes sense to the user; an opaque identifier does not. Even though people typically recognize the first few characters of opaque identifiers they frequently see, it is easier for an attacker to fool the user with a fake one. An analogy is a bookmark title versus a URL. There is also an example; we show the user URLs but never the corresponding IPv6 address. That being said, the opaque identifiers are important for debugging and tracing. Those UIs must show them, but I don't think they should be part of the application's interaction design. -------------- Alan Karp On Tue, Dec 31, 2024 at 9:38 AM Daniel Hardman <daniel.hardman@gmail.com> wrote: > A part of me is in violent agreement with the sentiment that DIDs are > low-level details. I think I get all of the reasons why it's desirable for > this to be the answer. > > However, another part of me is sounding a little bit of a dissonant bell, > at the back of my brain. I think we might be ignoring some important nuance. > > DIDs are points of control. We talk about "DID controllers". If a user has > points of control but doesn't know she has them, in what sense(s) is she > really in control? Pet names make points of control tractable from a human > memory perspective, but if the mental model of a user doesn't have a place > for the control point that they name, do we truly understand what we are > accomplishing? Do we need to? How does this relate to sovereignty? > > Each of us has many "points of control" over our physical body. > Understanding and using these points of control is an important > developmental task, and it is never "complete", only "mastered to level X". > We're born blinking autonomously, but we also have conscious control over > our eyelids very early and without instruction. We typically learn to wink > a few years later -- not hard, but takes a little focused intent that we > don't spontaneously come up with until we see it modeled. Eventually we > learn to ride bikes and play musical instruments and juggle and dance samba > with a partner and slow our heartbeats during meditation. These learnings > require us to discover and take advantage of control points... > > I'm wondering if intentional use of DIDs -- not *all* DIDs under a > person's control, but the subset of them that a person deems interesting > enough to pay attention to -- is an important outcome of a good "system". > I'm also wondering if a good "system" ought to understand which DIDs need > to be under conscious control early, which ones ought to be like eyelids > that are both consciously and automatably controllable, and which ones > should remain unconscious except in rare cases of troubleshooting or weird > requirements. > > On Tue, Dec 31, 2024 at 9:20 AM Alan Karp <alanhkarp@gmail.com> wrote: > >> On Tue, Dec 31, 2024 at 3:41 AM Merul Dhiman <me@merul.org> wrote: >> >>> This is a very interesting question which often gets asked to me. We >>> have always thought of DIDs and VCs as low level architecture details, and >>> that is where they shall belong its just a technology which allows us to >>> issue and digitally verify data. >>> >>> I think we never even need to tell the user about the technology which >>> lies underneath, as it is, for them totally not relevant. However we tell >>> them what we solve for them and address their pain points and empathise >>> with them. >>> >> >> That's the right approach, a lesson we learned from one of our projects. >> We built a file sharing application that used opaque identifiers (not DIDs) >> under the covers. The user only saw petnames except in one place. >> Wouldn't you know it? Almost every user complained about it. >> >> -------------- >> Alan Karp >> >> >> On Tue, Dec 31, 2024 at 3:41 AM Merul Dhiman <me@merul.org> wrote: >> >>> This is a very interesting question which often gets asked to me. We >>> have always thought of DIDs and VCs as low level architecture details, and >>> that is where they shall belong its just a technology which allows us to >>> issue and digitally verify data. >>> >>> I think we never even need to tell the user about the technology which >>> lies underneath, as it is, for them totally not relevant. However we tell >>> them what we solve for them and address their pain points and empathise >>> with them. >>> >>> >>> Best Wishes, >>> >>> Merul Dhiman >>> CTO >>> AuvoDigital OÜ >>> >>> https://auvo.io >>> >>> >>> >>> >>> On Sun, Dec 29, 2024 at 15:57 Michael Herman (Trusted Digital Web) < >>> mwherman@parallelspace.net> wrote: >>> >>>> An interesting related question for a UX expert is: If DIDs are >>>> low-level technology artifacts, what are the best/most appropriate UX >>>> metaphors to surface in real apps? >>>> >>>> Get Outlook for Android <https://aka.ms/AAb9ysg> >>>> ------------------------------ >>>> *From:* Michael Herman (Trusted Digital Web) < >>>> mwherman@parallelspace.net> >>>> *Sent:* Sunday, December 29, 2024 8:13:29 AM >>>> *To:* Kishore Rajasekharuni <kishore.rajasekharuni@jukshio.com> >>>> >>>> *Cc:* public-credentials (public-credentials@w3.org) < >>>> public-credentials@w3.org> >>>> *Subject:* Re: [External] Pop Quiz: Where do DIDs belong from an >>>> Enterprise Architecture perspective? >>>> >>>> Thank you for your analysis Kishore.When I say "DIDs", I'm being very >>>> literal: >>>> A DID = decentralized identifier = "did:wxyz:1234" character string. >>>> >>>> The answer to the question gets into the subtleties of decentralized >>>> identifiers (e.g. did:wxyz:1234).. They are not intended to be >>>> human-friendly or comprehensible (like a checksum or a GUID); hence in my >>>> mind, they are low-level technical/infrastructure concepts/elements - at >>>> the very most, the lowest levels of your application architecture >>>> (admitting this is actually going too far IMO). >>>> >>>> It would be interesting to revisit how a platform like .NET abstracts >>>> an identifier up the chain into higher level application objects like an >>>> Identity or Principal (.NET terminology). >>>> >>>> Michael Herman >>>> CEO and First Principles Thinker >>>> Web 7.0 Foundation / Trusted Digital Web (TDW) >>>> >>>> Get Outlook for Android <https://aka.ms/AAb9ysg> >>>> ------------------------------ >>>> *From:* Kishore Rajasekharuni <kishore.rajasekharuni@jukshio.com> >>>> *Sent:* Friday, December 27, 2024 8:34:31 AM >>>> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> >>>> *Cc:* public-credentials (public-credentials@w3.org) < >>>> public-credentials@w3.org> >>>> *Subject:* Re: [External] Pop Quiz: Where do DIDs belong from an >>>> Enterprise Architecture perspective? >>>> >>>> My understanding - DiD can be part of Party Management in the Business >>>> architecture layer. At the application architecture layer, it can be the >>>> Digital Identity module exposing APIs for Onboarding, Identity Proofing and >>>> Fraud Detection. The underlying Digital Identity Apps / Portals can be part >>>> of the Technology / Infrastructure architecture. >>>> >>>> regards >>>> Kishore >>>> >>>> On 27 Dec 2024, at 12:07 PM, Michael Herman (Trusted Digital Web) < >>>> mwherman@parallelspace.net> wrote: >>>> >>>> Are DIDs part of the: >>>> - Business architecture/layer/domain >>>> - Application architecture/layer/domain >>>> - Technology/Infrastructure architecture/layer/domain? >>>> >>>> Get Outlook for Android >>>> <https://www.google.com/url?q=https://aka.ms/AAb9ysg&source=gmail-imap&ust=1735886469000000&usg=AOvVaw3dZOsMm5uX8vKzgHgmZY6E> >>>> >>>> >>>>
Received on Tuesday, 31 December 2024 18:18:48 UTC