[MINUTES] CCG Weekly 2025-08-05

W3C CCG Meeting Summary - 2025/08/05

*Topics Covered:*

   -

   *No Phone Home Principle:* The primary focus was a discussion on the "no
   phone home" principle within decentralized identity systems. This principle
   advocates against systems where credentials must contact the issuing
   authority ("phone home") for verification, emphasizing its conflict with
   decentralized identity's core tenets.
   -

   *Mobile Driver's License (MDL) and Server Retrieval:* The discussion
   centered heavily on the MDL specification and its "server retrieval"
   method. This method allows verifiers to contact the issuer for validation,
   raising significant privacy concerns due to potential tracking of user
   interactions and locations. The presenters showed how this was implemented
   in Utah, causing alarm and a subsequent shutdown, highlighting the lack of
   awareness and control among implementers and the potential for misuse.
   -

   *ISO 18013-5 Specification Analysis:* A detailed analysis of the ISO
   18013-5 specification revealed that while server retrieval is technically
   optional, it's often practically mandatory due to interoperability concerns
   and vendor incentives. The specification's use of terms like "recommended"
   was highlighted as potentially misleading.
   -

   *Cross-Jurisdictional Issues and Interoperability:* The challenges of
   cross-jurisdictional interoperability were discussed. If one jurisdiction
   disables server retrieval, it can break interoperability with other
   jurisdictions that utilize it, creating a dilemma for privacy protection
   versus interoperability.
   -

   *Technical and Sociopolitical Alternatives:* Technical alternatives were
   discussed, such as verifiable credentials with proof of non-revocation and
   oblivious HTTP. Sociopolitical alternatives, such as policy changes and
   legislation, were also considered, but their fragility and dependence on
   political climate were noted.
   -

   *Community Consensus and Future Actions:* Strong community support for
   the "no phone home" principle was evident. Concerns were raised about the
   mischaracterization of the issue by some MDL implementers. The meeting
   concluded with a call to action to promote better defaults, clarify the
   implications of optional features, and push for improved standards and
   community advocacy on baseline privacy protections.

*Key Points:*

   - Server retrieval in MDLs enables tracking of user activities and
   locations.
   - The ISO 18013-5 specification's language regarding optional features
   (like server retrieval) is misleading; in practice, it's often required for
   interoperability.
   - Utah's experience revealed implementation of server retrieval without
   sufficient understanding of its privacy implications.
   - The "no phone home" principle is fundamental to decentralized identity
   and should be a priority.
   - While enterprise use cases might benefit from phone home, this must be
   balanced against the broader privacy implications for citizens. Alternative
   designs are needed to appropriately address the needs of both.
   - The community needs to push for better standards and defaults to
   prevent the erosion of privacy protections.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-08-05.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-08-05.mp4
*CCG Weekly - 2025/08/05 11:51 EDT - Transcript* *Attendees*

Alan Karp, Alex Higuera, Benjamin Young, Chandima Cumaranatunge, Dave
Longley, Dmitri Zagidulin, Elaine Wooton, Erica Connell, Fireflies.ai
Notetaker Ivan, Geun-Hyung Kim, Greg Bernstein, Gregory Natran, Harrison
Tang, Hiroyuki Sano, Ivan Dzheferov, James Chartrand, Jay Stanley, JeffO -
HumanOS, Jennie Meier, Joe Andrieu, Kaliya Identity Woman, Kayode Ezike,
Ken Griggs, Kerri Lemoie, Kim Hamilton Duffy, Mahmoud Alkhraishi, Manu
Sporny, Nick Ris, Otto Mora, Parth Bhatt, Pavol Hrina, Peter Bachman,
Phillip Long, Rashmi Siravara, Sharon Leu, Steven McCown, Ted Thibodeau Jr,
Timothy Ruff, Vanessa Xu, Venu Reddy, Will Abramson
*Transcript*

Phillip Long: Good morning, Harrison.

Harrison Tang: Good morning. Hello everyone.

Alan Karp: I see a lot of The gray beards join earlier. Is that the
convention here?

Ted Thibodeau Jr: Did you not get the memo?

Alan Karp: I joined early so without the memo.

Ted Thibodeau Jr: Rebeard psychic superpowers.

Alan Karp: You caught me.

Harrison Tang: All right, we'll start in about two minutes, but Thanks
everyone for jumping on time. So, let's give everyone else about a minute
and we'll start right away.

Harrison Tang: All right, we'll start this week's W3CC meeting. so today
we're very excited to have Kim, Joe, and Steve here to lead a discussion on
no phone call home. so this is likely the most controversial topic in the
last 12 month. so this is going to be a very exciting discussion. Now just
a quick reminder on the code of ethics and professional conduct.

Harrison Tang: just want to make sure we hold respectful constructive
conversations let's make sure that we assume good intentions from everyone
we might have different perspectives but I think we all coming from a good
place right there could be different context for different solutions and
different designs let's make sure that we keep dialing our goal is to
figure out why in some situations to walk. So I think we have been holding
very great conversations in the past two three years and let's make sure we
continue to do that. a quick note on the international property anyone can
participate in these calls however all substances to the CCG work items
must be member of the CCG with full IP.

Harrison Tang: It's actually quite easy to do that. If you have any
questions about getting the W3C account or the contractor license
agreement, please feel free to reach out to me or any of the coaches. These
calls are being automatically recorded and trans So you'll the
transcription, the video, and the audio recording will be automatically
sent out in the next 24 hours. let's take a quick moment for the
introductions and re reintroductions. So I see a lot of new faces. if you
want to just introduce yourself feel free to just unmute. I'm not going to
call on people.

Harrison Tang: Let's get to any announcements reminders. we have a pretty
full agenda for the next few months. So, if you want to preview what's
coming, here's the link to the W3C CCG calendar. Just a quick note. it's
not just the CCG calls. There's also VCAP. Wednesdays there's incubation
and promotion of different work items. Fridays there's data integrity and
then there's VCU. So all the dates actually in this calendar. So feel free
to just go to the link and then take so next week we will have Drummond to
actually talk about the first person personhood credentials project.
00:05:00

Harrison Tang: Yeah. All right, Kia. Thanks.

Kaliya Identity Woman: I just want to say that IW's coming up October 28th
to 30th in Mountain View, So, everybody's invited. Should be really great.

Harrison Tang: Thank you. Any other announcements reminders? Yes.

Timothy Ruff: I'll make an announcement real quick. U you able to hear me?
So, the state of Utah is not publicized this yet, but they're going to be
hosting an event for SETIC SEDI, which is state endorsed decentralized
identity for policy makers on Friday, October 17th, and the day before for
the general tech industry. so anybody here who'd want to come and it'll be
held at Utah Valley University on Thursday the 16th and for policy makers
only on Friday the 17th.

Harrison Tang: Thank Thanks. Any other announcements any updates or
questions on the CCG work items? As so we just had a great quarter two
review of boards which were 15. We have since adopted two new work items
and we will review that again September 30. So about three months. All
right. Last calls for ductions, reintroductions, announcements, reminders
for guidance. All right, let's get to the main agenda.

Harrison Tang: So again very excited to have Joe and Steve here to lead a
discussion on no phone home. as most of us know but I think this might be
new to some people is that a phone home is basically a mechanism where ing
when the data the holders are presenting the credentials to the verifiers
the credentials will actually phone home or actually connect to the issuers.

Harrison Tang: so there could be some advantages but at the same time
obviously it could enable some kind of surveillance. so that's what phone
home is. I'm pretty sure Kim and others will actually describe what it is
for people who are new to the topic. But this is a very interesting
discussion. We had couple long threads about it. so I think this is going
to be a great conversation and Kim please take it away.

Kim Hamilton Duffy: Thank you and thanks for inviting us. And the principle
of no phone home has been pretty fundamental to the credentials community
group since the beginning. In fact we have a slide that shows how it's
called out as a specific goal in the verify credential data model use
cases. So, we're excited to share details here and I invited some of
basically the collaborators behind No Phone Home and very happy that
they've all joined us today and we will take turns presenting some slides
but we plan to leave plenty of time at the end for Q\&A. So, I'll turn over
first to Timothy Ruff to get us started.

Timothy Ruff: Thanks, And thank you everyone. the statement that's on your
screen, I imagine each of you have seen it's fairly simple. It just
basically says that we don't want policy makers to implement systems that
phone home and describes very simply what that means. We don't want an
identity system to be interacting with checking back with the original
issuing authority. and it's unnecessary. Frankly, the whole decentralized
identity industry exists to get around this problem. And you can't have
decentralized identity if every time an identity is verified, it has to
phone home to some authority. So, it is actually at its foundationally
antithetical to the whole concept of decentralized identity. And just a
little bit of background on how we got started.
00:10:00

Timothy Ruff: Kim at IIW walked up to me during the dinner time and she had
her plate and I was at a table and she came sat next she said maybe it's
just you and me anymore kind of frustrated and we were commiserating a
little bit about the prevalence of phone home systems and the lack of
concern about the privacy implications and it seemed like just kind of a
gradual erosion of decentral centralized identity principles. And so while
we were commiserating, we recruited Steve Macau, Joe Andrew, and Jay
Stanley to host a session the next morning and to repeat some of the things
that Steve Macau had already been presenting that he found with the MDL.
And it was wellreceived and there was a lot of certainly controversial with
some, but well received by others, very polarizing in we think a helpful
way.

Timothy Ruff: And then we decided after IIW that we would create a
statement and get some signers and that was led by Jay Stanley with the
ACLU. And once the ACLU started throwing their weight around then it really
got serious. So that's kind of the gestation of this. Go ahead and go to
the next slide. so this just shows what Kim was just mentioning that this
is a bedrock principle of this community to avoid phone home. And if you
think about it, you can't have decentralized identity if the identity
system has to phone home to some authority that it literally is
antithetical to the whole concept. So it should be shunned like the plague
by everyone in this community in my opinion. I'm speaking very very
strongly opinionated certainly happy to hear someone disagree with that but
it seems antithetical to me. go to the next slide and this is the last
slide I was going to cover. A little bit of background.

Timothy Ruff: Steve Macau who's going to be taking over right after me on
the next slide presented basically the text of the ISO 18013 5 spec where
it talks about the server retrieval elements and he brought receipts and
it's interesting because the ISO way of developing standards is not an open
standard system I mean you can call it an open standard

Timothy Ruff: but not most people have purchased it. You have to buy it to
get the exact text of it and know what's in it. So, he Kim bought it, I
bought it. we looked at the text and Steve took some screenshots, had
created a presentation at IW where he basically showed us the smoking gun.
And he's going to show all of you here in a moment what we saw. And the
smoking gun meaning here's what server retrieval does inside of the mobile
driver's license. And it's not just the MDL. the statement is general.

Timothy Ruff: It's about any system that does phone home. but the MDL has a
lot of momentum. It's being adopted in a lot of places and I'm summarizing
the points on this slide here. but the reason we focused on the MDL is
because it has a lot of momentum and it is being implemented and we
discovered in my home state of Utah, it says a US state, it's Utah. and
maybe this happened in another state as well, but I know this happened in
Utah that they did not understand what they had done.

Timothy Ruff: They didn't understand what server retrieval was doing and
what it was capable of. and they frankly didn't even know that it was
happening. It was just a recommended implementation. It was implemented
that way. And as soon as Utah became aware of what was happening, they
turned it off and were alarmed. And now we're campaigning against it. And
so there's going to be some serious push back from the state of Utah on the
mobile driver's license as a result. So, I'm going to stop there, hand it
over to Steve. He's got some receipts to share. And u Thank you, Steve.

Steven McCown: I'm happy to be here today. Thank you for the opportunity.
as Timothy mentioned, that's kind of the genesis of how this came about.
from my personal backstory. in a previous occupation, I worked as a red
team vulnerability researcher where I would look for things that could be
misused. And so a lot of times we build software with the intent of how
does this accomplish whatever goal we're attempting. And that occupation
for me has forever changed my mindset into how could somebody misuse the
good things that we've created? And the MDL has some really cool aspects to
it.
00:15:00

Steven McCown: but they have these others that I think draw away from that
quite a bit. So yeah a couple of us gave a talk at IAW last and it was
hurried together because of the opportunity to do so. And so if you go look
at you can see all the slides there in the IDW proceedings or on that link
that's on the page. They're pretty rough. So, we're trying to clean this up
some of it a little bit. so let's go on to the next slide. I know you're
all technical and you're probably very familiar with this, so I'll not go
into too much detail about how things work and I'll limit my comments to
what we observed and how it might cause a problem.

Steven McCown: So with the MDL, it's kind of the issuer holder verifier
model that we've all talked about. but the part that really got our
attention was that there are two methods of retrieving your license data.
And so the first one is device retrieval. And that looks very much like
self- sovereign digital identity, whatever you want to call where we use
that issuer holder verifier model and we like that it works pretty good.

Steven McCown: but as Timothy mentioned a lot of states particularly here
in Utah we found that it had been implemented using server retrieval. And
in a nutshell what that means is that the holder has a credential that they
will provide to the verifier. And in the case of device retrieval, the
information is contained within the data the holder possesses. Whereas in
server retrieval, it is contained back at the issuing server. And so the
verifier needs to call the issuing server, thus phone home, and say, okay,
I just got this particular MDL expressed to me. is it valid? What other
information do I need?

Steven McCown: and all that kind of stuff. And so the act of contacting the
issuer each and every time a credential is verified creates a situation
where a user's interactions and locations and purposes can be tracked by
the issuer. All right, next slide. So, we like the three-party traditional
SSI model. but this kind of makes it in a way kind of the three and a party
kind of a four-party by phoning home back to the issuer.

Steven McCown: And what happens is good cyber security policy will say that
all computer accesses need to be logged and they need to be logged for a
period of time and that is totally dependent upon the server owner operator
how that's done but it gives them the opportunity to say Joe went to the
gas station and bought this or expressed their credential in order to do
something at the department of motor vehicles or to get a fishing license
or any of those types of things. And with Apple's announcement about MDLs
at WWDC here a little bit ago, the intent is to take MDLs and make them
available to use as web authentication and web login.

Steven McCown: So the concerns that we've had about maybe the state know
when somebody buys alcoholic beverages or does something with their fishing
license or whatever traditional things MDL is intended for. By coupling it
with the web, we've now created a situation where the logging can expand
dramatically to anything we do and wherever we go online. And I know that
that wasn't intended, but that's kind of what happens when these
capabilities are available and they just kind of evolve and they go just
move forward. Somebody says, " I need an identity system for my website."
And this is a good one. Let me piggyback on that. and that's how these
things kind of evolve.
00:20:00

Steven McCown: one of the things that we found according to the
specification and this is highlighted more in the other slides that are on
the bottom of the page is that a state can change from device retrieval to
server retrieval without knowing notifying anyone. And what happens is when
an issuer makes that change to go from device retrieval to server
retrieval, what happens is there's notifications sent out to each of the
holders and they need to launch whatever wallet app state driver's license
app that they're using and then magic will happen.

Steven McCown: the protocol will take over, a new slide will or a new
credential will be downloaded from the issuer and so forth. And we saw that
in Utah because as Timothy mentioned, we found that Utah had implemented
his server retrieval. And once we explained what that was and that it
wasn't necessary, they immediately turned that off. And so that caused a
kind of a cascade of every credential that had been issued to be to have an
update request that holders needed to service. And they didn't really need
to know what they were doing, just that there was an update and the text
message that came out said, "There's an update to your end deal. Please
launch your app and it'll be updated." And so it can change.

Steven McCown: going beyond that, we found that it wasn't just that the
state itself could change everybody's MDLs, but they could be targeted to
specific individuals and only certain MDLs could be updated from device
retrieval to server retrieval capability. And so with all the tracking and
the logging that I just mentioned, this could be focused on a very
particular individual. maybe somebody has a reason to be a person of
interest. Maybe they have political leanings that are different than the
prevailing authority. Whatever the case may be, we found that it could be
very targeted to specific individuals. all right.

Steven McCown: so one more thing that we found here in the state of Utah is
that the interoperability portion of the MDLs which is really cool by the
way it's really helpful but what it does is it means if our state for
example turns off divi server retrieval because we have a different view on
how privacy might need to be maintained. what happens when someone comes
from a different jurisdiction.

Steven McCown: it could be a different state, different country and
presents their MDL using server retrieval if that's how it was created out
at one of the venues here in the state, then that venue ends up taking
participation in the surveillance or phoning home activities of the other
state's resident as they move around and do things here in our state. And
so that's one of the problems. Now that one cannot be turned off. if you
disable server retrieval for externally issued credentials then what
happens is you just break interoperability there. There's not like a
halfway in between.

Steven McCown: So if somebody comes presenting a credential with server
retrieval then you either accept it or you don't and you have
interoperability or you don't and so some states in particular ours don't
really want to participate in phone home type surveillance to those other
issuers even though that's the way the specification needs to operate. All
right.

Steven McCown: go ahead. Next slide. so what we found, so this is a little
bit different and you can take a look in the spec, but basically there's a
bunch of things in the spec that say they're accepting things that are
optional, it really is optional. You don't have to accept them, but there's
some downsides. for example, verification terminals. it is optional whether
they support server retrieval or not. The problem is in order to be
compliant with the standard they kind of need to put that in there. I mean
who wants to go to their boss and say we just worked for a year and a half.
We created this expensive piece of hardware we want to sell to do MDL
verification and because of privacy reasons we eliminated server retrieval.
00:25:00

Steven McCown: Therefore, now we're not interoperable with anybody. that
would be a career or at least that job killer. because you don't want to go
to your boss and say, we just made ourselves uninteropable with other
credentials from other venues. So, yeah, a lot of times it says in the spec
certain things are optional, and we found that to be practically not the
case, even though it was technically still true. next slide. All right.
yeah. And here's another view. this is one that Kim found in the spec where
if you look in the matrix here down the left hand side, you see server
first you see device retrieval and then you go over to under support where
it says MDL reader.

Steven McCown: device retrieval items are mandatory other than Wi-Fi, but
when you get to server retrieval, they're recommended. And that's one of
those cases. what really does recommended mean? and so there's some
confusion there. And this is what happened in our state. our state had no
desire to create data logs of all MDL uses but because it followed the
specification and set up their systems according to the recommendations
that's what they had created and once we did some analysis figured out that
that was what had happened we talked to the state and they by themselves
went and turned that off and deleted all the logs that had been recorded.

Steven McCown: but that's whether it's optional, mandatory, recommended,
conditional even are kind of a little bit misleading. So next slide. So
yeah, the real question there's a couple of questions that we've found are
important to ask. Will the r issue By that what we mean is will the issuer
use server retrieval or will they not and how will using so what happens is
the credential that's contained in the wallet on the phone actually has
some data elements in there that tell the verifier terminal when a
credential is expressed that credential is using server retrieval or device
retrieval.

Steven McCown: So using, cyber security tools, you can peek into the
sandbox of another app. Yeah, it's hard, but you can do it and you can
figure out what your credential is using, but most people don't have that
capability. And unless the wallet provider has decided to say, hey, you're
using device retrieval or you're using server retrieval, which would
probably just confuse most people, then it's really kind of an unknown. And
as we demonstrated here in Utah, you can turn one mode off and enable the
other mode and all anyone ever sees is that there's an update and it
doesn't have to explain what the update is. on the reader side, yeah, I
think readers kind of are in a bind where they have to implement both modes
or their value proposition is not being interoperable, which would probably
very much limit sales.

Steven McCown: So even though it's called recommended and optional, it's
effectively, from a financial perspective, it's not. and so yeah, this last
question is kind of a brainstorming question of what other things have now
that we have server retrieval and everything that gets recorded, what else
can we do with that? So that's things like when the verifier terminal
phones home, they're going to use TCP IP traffic just like anything else.
And what that will do is it will reveal their IP address, which is probably
already known somewhere, but that can be turned into g GPS coordinates.

Steven McCown: the NSA has a patent on how to do that and that's been
around for kind of a long time. but any of those things that happen, any
other data that might be solicited, it can all kind of be recorded. And the
bottom line here is even though these things are optional, if it exists,
somebody's going to find a reason to turn it on. I mean, if we followed
Apple's method and we used MDL to get onto a website, in another previous
occupation, I helped stream the very first, geographically sandboxed Major
League Baseball team in the United States.
00:30:00

Steven McCown: and so what we did is we tried to limit distribution of the
viewing of that game by geographic location and so that's something that
you never know there's all sorts of other information and so the act of
phoning home isn't just for information that's in the MDL specification.
it's for things that can be derived from that specification. So, that was
kind of a lot and I didn't read all the questions while we were doing this.
do we want to talk about any of those questions right now or kind of wait
till the end?

Kim Hamilton Duffy: And one quick point I'm going to make is that I'm going
to edit bullet point number three to say what else can the issuer learn
with or without the user's consent and will there are some interesting
questions here I think in the ISO specifically issues of consent and there
are all kinds of kind of murkier notions of consent in there like
preconsent and then consent based on proximity that I think would need to
be teased apart because I think that they're not necessarily obvious to
implementers to users things like that.

Kim Hamilton Duffy: There are a lot of tricky areas that will boil down to
sort of jurisdictional requirements and we'll get to Phil to add some more
nuances there. And I think let's leave questions to the end. we only have a
few more slides. let's see. I think let me get back to this one.

Kim Hamilton Duffy: Why is this different? So Steve, I had you covering
this one. You want to finish us off with your part of the presentation?

Steven McCown: Yeah.

Steven McCown: So generally speaking, when it comes to privacy and
surveillance, people don't really always know. they know they want to be
provide private and they don't want to be surveiled, but they don't always
know when that's happening or how it's happening. so that's incumbent upon
us to create systems that are inherently privacy pro protecting and that
are still very cryptographically secure and and so whenever there's data
collected there will be a reason to use it later that maybe the designers
didn't envision.

Steven McCown: And so it's best to not create as many things that get
logged. So that's it.

Kim Hamilton Duffy: And sorry for the glitches.

Kim Hamilton Duffy: I'm on a very big screen so just trying to get it to
the right view. Thank you so much, Let's see. The more we thought about it,
the Steve's point about the crossjurisdictional considerations in general
introduced a lot of interesting and tricky questions. So, when you think
about a driver's license at minimum, how often it's even used varies a lot
based on where you live. So, in the US, we use it. ever since Steve's
presentation, I think about my driver's license every time I use it, making
note of, is someone scanning it? Are they just looking at it? did they even
request it? And we use it often, all the time, and for non-driving
purposes. In fact, I guess this is a good thing.

Kim Hamilton Duffy: And lucky I was not getting pulled over by police or
interacting with the police that often, but they were all non-driving
purposes. So proving age when accessing an age restricted product is a
common one in the US. Picking up a prescription, picking up a shipment. And
so in some cases, as you know, if you use your driver's license, sometimes'
the physical driver's license, sometimes they'll scan it. So that would
result in sort of the logging potential tracking. But in many cases what I
found was that people were just looking at it checking that the photo
making sure it's me. No record was being made.

Kim Hamilton Duffy: so that's just focusing on the US and there's variation
within US states around which required barcode reading but some countries
have a national ID in cases like the driver's license wouldn't even be
used. So it's very interesting question around if you're talking about a
latent surveillance risk if people are even using it and what you could
potentially correlate depends greatly on where you live. So then the other
factor that depends on where you live it are data protection. So in the US
we have no comprehensive data protection framework like the GDPR.
00:35:00

Kim Hamilton Duffy: So many of the risks called out in the ISOspec I think
it's appendix E that are sort of said implementers know that this is a risk
deal make sure you deal with it in the case of many locations in the EU
there would be some control for it or some requirement around what apps can
and cannot do in the US we generally assume lowest common denominator
unfortunately and that's again just focusing on locations that we often
talk about in this forum. So how to deal with risks is left to implementers
who may not understand implications. That's what's really interesting about
the Utah case which we touched on.

Kim Hamilton Duffy: As noted, the state of Utah did not want server
retrieval, but in a series of totally reasonable technical decisions. the
server retrieval was in fact the preferred implementation and it's because
the implementers observed, server retrieval is more reliable and more
efficient than using Bluetooth retrieval. So, let's just use that. And so
that was a case where when the chief privacy officer of Utah learned that
in fact the preferred implementation it was not very popular with the state
and…

Steven McCown: What's that?

Kim Hamilton Duffy: they made quick actions to overturn that. but that was
a really good case of ISO has appendix E that says here are all the risks.
AMBA also has their guidance for US states for talking about in the US
context for example or North American context. and then they call out risks
and note that they have said for MDL implementers, they're now saying it's
banned in the US. So that's a good move. It doesn't address the cross
jurisdictional reader concern that Steve mentioned.

Kim Hamilton Duffy: But in any case, this is a really good example of how
the risks get punted to ultimately in the context of North America to the
US states and did they meticulously read every appendix of every
specification guideline etc that came in and I think as Steve points out
implementers are sorry, incentivized to implement full spec. So, they want
to make sure they're not ruled out of procurement. So, it's better for them
if they say I check all the boxes and warnings shoved to appendices may not
be clear to decision makers. Timothy, is there something you want to add
here? you're muted.

Timothy Ruff: I just wanted to be on the queue for when you're done.

Kim Hamilton Duffy: we're getting close. so the other thing that's
interesting is there are technical alternatives. That's what this group,
when I started participating nine years ago. That's exactly why I joined.
So we had a group of people that wanted to build towards a three-party
model where issuers can continue to control the credential life cycle. They
can revoke credentials while avoiding phone home. We saw that just towards
the beginning in the VC use cases document. we've been in this community
and beyond building the technical elements to avoid phone homes.

Kim Hamilton Duffy: So the bitst string implementation in verifiable
credentials, a nonredit which uses proof of non-revocation which avoids
phoning home and technologies like oblivious HTTP. all of these have been
developed to avoid these risks and so it brings up questions of why are
these not being used and then even does the credential more pointed
question does the credentials community group continue to stand by this
principle?
00:40:00

Kim Hamilton Duffy: and does it need to help promote or improve
alternatives? So that this question is why is this controversial? This is
where I think when Timothy and I had that conversation it just felt like
what's happening here? why are we compromising on this principle and many
other principles of self-s sovereign identity that we felt were fundamental
to the community from the beginning. so I want to tee up Phil to touch on
sociopolitical alternatives.

Kim Hamilton Duffy: Then we'll be at the end roughly in discussion. So Phil

Phillip Long: Thank you.

Phillip Long: And my followup is simply an underscore of what Steve and I
believe Timothy have already said. And there are in fact policies that can
be implemented that instruct implementers not to do server retrieval. We've
heard that discussed. one can go further and make actual statutes or laws
that are legislatively adopted. And in many states, there are avenues for
public referenda which can make amendments to a state constitution, among
other things, to make it even harder for a change to be made. The fear for
all of those sociopolitical alternatives is that they're fragile and
dependent on the environmental of polit policy climates in those instit in
those states.

Phillip Long: by virtue of who the leadership happens to be at the time. So
you may have a whipssaw thing where different policies get implemented
depending on who happens to get voted into office in a particular election
and that doesn't help anyone. the last thing to say is simply that policy
by the security by policy is among the weakest and least useful of the
mechanisms to address this problem. even if it seems as though it might be
helpful. And I think just that needs to be underscored because people will
say, we agreed to do this and we put this pl rule in place and now we're
done." And it fades the background and then someone switches it on because
they have an interest in doing so and there's some policy change that's
made or an amendment or alteration to it and you're back to where you
started from without even knowing it.

Phillip Long: So that is I think the important thing to remember as we go
forward. ideally if it is pulled out of the ISO spec as rumor suggests it'
be a great change. I was wondering whether or not a clone of this
implementation that does pull it out, whether ISO agrees to it or not, is
an alternative. So that there is actually code that just doesn't have that
option in it, but everything else there that is in the ISO spec is retained
that people potentially are interested in.

Phillip Long: Maybe that's an option down the road, too. Thanks,

Kim Hamilton Duffy: So I'll take this closing slide.

Kim Hamilton Duffy: A key takeaway is optional is not neutral. I mean, this
is something the community here has strived for years is, how do we make
sure that we're getting a broader set of, society input into the specs that
we're, designing? How do we make sure that we're designing for a range of
contexts and the standards we set today will determine protections of
tomorrow. So, we cannot build these in a vacuum.

Kim Hamilton Duffy: So some open-ended questions include how can we push
for better defaults and standards? How can we identify where optional is
likely to become coercive in the case of implementers? And are there
baseline protections that CCG should advocate? So I think we have a lot of
discussion. I want to close it here for next steps. Thank you everyone.
I'll call on Timothy and then turn back to the chairs to take questions
from the audience. to the feet.

Timothy Ruff: Yeah, I want to share what I think my colleagues who were
behind the no phone home thing, Kim, Steve, Joe, and Jay would also say and
go back to our statement and that is that we oppose phone home. We don't
care who the offender is. We're talking a lot about the MDL. There's been
some mention about connect or whether it's in Open ID VC or VP. it really
doesn't matter. I don't care what spec it is. If it phones home, I don't
like it. and I don't think it's conducive to what we're trying to do from a
privacy standpoint or autonomy standpoint with decentralized identity.
00:45:00

Timothy Ruff: And so to Kalia's point in the comments, 100% we need to be
accurate about phone home so we know which things to oppose. And if
something doesn't phone home, it might have some other problem, but I don't
want to inaccurately accusing of phoning home. But if Open ID VP or VC
depends or expects an implementation of Open ID connect, which phones home
inherently, then it's a problem and I would oppose it. So, it's nothing
personal. We're not trying to get on the bandwagon or accuse. That's a very
strong word. We're trying to be very fair about what phones home and what
doesn't. And if it phones home, we don't like it. And if it doesn't, then
it's fine. So, I want to be very fair and accurate about these things. And
so, for future conversations, we're not having the full conversation about
it's not part of today's presentation about other specs that might phone
home. a little bit in the comments was addressed.

Timothy Ruff: So, if there's going to be future conversation about these
things, I would just encourage the group to be clear about what phones home
and what doesn't and draw the line there.

Harrison Tang: Mommy, please. Funny.

Kim Hamilton Duffy: Thank you. Back to Harrison.

Manu Sporny: Yeah, so first off, I really wanted to commend each of you for
putting the no phone home statement together and rallying the community
behind it and getting such strong support of it. I mean there, 40 people
here today. I think that very much underscores that the community cares
about this topic deeply and I think the vast majority of us agree with that
statement. I meaning the phone home statement. So Kim, you had asked, does
this community still believe that in that? I think that's why so many
people are here in support. I went to the federal MDL day two weeks ago and
this topic came up.

Manu Sporny: In fact, it specifically came up. and I was pretty
disheartened with the response from the individuals on the stage. This is
publicly recorded. I haven't gotten the link right now to them, but I'll
try to send them to the mailing list. But the response from those deploying
MDL were statements like, "It is not true that server retrieval was ever
implemented in the United States. It has never been implemented. and
therefore the people that are making these accusations are not being
truthful about server retrieval. That was one of the statements. The other
statement was these are a bunch of paranoid people that are trying to sell
their own solutions and for that reason this is just a paranoid response.

Manu Sporny: and then the least u u u costic comment I heard was they are
completely u misrepresenting what the specification it doesn't say to phone
home in the way that they're saying and so on and so forth. So, the reason
I'm saying this, I disagree with every single one of those statements, but
that was the response at federal MDL day in Washington DC with everyone
that's deploying MDLs. I do think the initiative has been very successful
in raising awareness and I think they didn't have to cover it. They just
did, mention it. So, I think that's a positive outcome.

Manu Sporny: But I think that's the other concern that I have is that there
are a number of us that have been saying this for years that have provided
feedback for years. and it does look like this time it finally cause a
change in the specification. but I am concerned about the continued
mischaracterization of the core message. so I'm wondering what do we do
about that? because I think it resonated among the people that care about
this stuff and for the people deploying it, the other vendors, it was just
blown off as this bunch of paranoid people just wanting to sell their own
own thing. thoughts on that.

Timothy Ruff: I'd like to say something about that. I don't care who is
selling stuff that doesn't phone home. Whether it's my grandma, I Uncle
Fred, I don't care. I want products that don't phone home. And so that is a
complete red herring if someone's going to say, "Well, they're just selling
another thing. it really comes down to does it phone home or not? that's
what the statement is about. And if someone's going to make just a
factually erroneous claim that Phone Home didn't exist, that's just simply
wrong. It's disingenuous. And it speaks to the integrity of the people
making those claims.
00:50:00

Kim Hamilton Duffy: I will add. go ahead.

Steven McCown: And I'd like to follow on with that.

Steven McCown: So, whoever made the comment that no US state ever
implemented it that way? Utah did. and they followed the ex explanations in
the specification and we know that because they had to turn it off and the
CIO personally told me that and so from talking to others I understand that
other US states have done the same thing and I say I don't think it was
malicious in any way.

Steven McCown: I don't think it was intended to be a surveillance, but the
facts the fact that it was turned on was just people following the
specification and that it could be misused. That's why we need to be
concerned about that because hackers read the manual and then they figure
out what else they can do. And it's like the old TV show MacGyver. That's
who hackers are. They figure out what they have and what they can do with
it. And so that's why phone home has been a concern for us.

Kim Hamilton Duffy: And lastly, the disin how do you say ad hom attacks and
they may not be as effective as they think they're being. In fact, it was
exactly those kind of accusations. LinkedIn starting about a year ago when
Timothy has been raising awareness about this for a while as has Jay etc.
It was the responses like that saying, " what do you have to sell?" and
things like that that made my spidey senses start tingling and why I
started being suspicious about what's going on here. so yes, keep the
attacks coming I guess.

Harrison Tang: By the way, Stephen, earlier there's a question in regards
to what other states are following kind of Utah steps. So what are the more
specifically the state of Iowa how does different state implement the MDL?

Harrison Tang: Do they include phone home? can you kind of share the stat
kind of overall status of the land?

Steven McCown: Yeah. …

Steven McCown: which states specifically other than Utah? I can't really
answer that directly. I have firsthand knowledge of what Utah had done and
why they had done it, meaning they were just following the standard. and so
I imagine most other states had done the same thing. a couple other states
I'm not entirely sure on the name so I'm not going to name them but it was
intentional that they wanted it that way. So, what in response to bringing
this up at IAW, I asked a question of the AMVA presenter at EIC in Berlin a
couple months ago and they had already talked about this and started the
process for updating the AMVA recommendation to recommend or to require
actually that no US state use this.

Steven McCown: So, I think wherever it was that we were and we might have
fun, kind of debating over that, AMA's done the right thing in this case
and that they've turned that they've required that to be turned off, but
that still doesn't eliminate the fact that there's a button. it's not
really a button, might take days or weeks to actually implement, but
effectively there's a button somewhere that can turn it back on. and…

Harrison Tang: Thank you, Alan.

Steven McCown: that's kind of what we're also pushing back against is the
ability to turn it on, not just whether it's on.

Alan Karp: Just a simple question. an enterprise has a legitimate need to
know when its credentials are being used. does that mean that this standard
is just not appropriate for that use case?

Steven McCown: So, if I could answer that. so there's a couple of
different, let me call them societies, if you will. your corporate society,
you're employed by the corporation. they put tracking software on virus
scanning among other things. They put a lot of things on quote unquote your
laptop, because you work for them, you're at the behest of their venue. we
don't see citizens of a government in the same light. So when it comes to
what your government should or shouldn't do in regards to phone home versus
what your corporation should do. those are kind of different scenarios. So
if one standard services the enterprise standard better, that's awesome.
00:55:00

Steven McCown: But we need to be clear on when and how things are used and
why. So because in the past I worked for the US government and we did a lot
of things. We purchased a lot of software and hardware that's called
commercial offtheshelf cuts. And the reason that all came about is we saw
something that was working really good in the private sector. And we
thought, let's modernize government and all of our processes and make it
all work better. We'll use that. We'll save money versus, subcontracting
for somebody to build a new piece of hardware with a bunch of new
protocols. And so that's why this is kind of a problem. So yes, you're
absolutely correct. would that be appropriate in an enterprise? Yeah,
probably.

Steven McCown: But as those specifications migrate across industries, each
industry has a whole lot of diverse requirements. Yeah.

Alan Karp: So the answer is it without phone home that the standard is not
appropriate for that use case.

Alan Karp: That's a fine answer.

Harrison Tang: Bill, good.

Harrison Tang: Thank you, Bill. I also Okay, you might be on mute.

Phillip Long: Yeah, I am on mute and I was doing so because I was trying to
remember what I put my hand up for. I think that there are examples of use
cases where phone home is in fact potentially a safety issue and necessary.
One of those was brought to my attention for people fighting forest fires
and knowing exact location of where someone is at that point in time could
be very valuable. so it's not that the idea is inherently wrong.

Phillip Long: The question is it inherently wrong in the context of the
implementation where the driver's license is used as a generic device for
multiple purposes and there may be very valuable reasons why in one
particular context it's helpful but as was Steve mentioned if it is in such
the baseline by which any citizen using a phone with their driver's license
can have it implemented and I'm particularly concerned about have it
implemented with nothing on the individual screen to say that that's the
method of verification at this point in time being requested. I would feel
better if that was there. although like someone mentioned in chat requiring
consent for every little thing you do often makes the consent a knee-jerk
response as opposed to a thoughtful response.

Phillip Long: so there are concerns about how much friction we really think
the system should have in this context and when to impose it. But in this
particular case I think knowing that there is an essential step for those
places where it's a valuable thing to have.

Harrison Tang: Great.

Greg Bernstein: I may have come in a little bit late and I know Kim knows
this issue the phone home kind of gives real time tracking unique
identifiers in an ID gives us linkability and this ability to track just if
the verifier is in collusion with whoever. Right? So, particularly in the
states where my driver's license California, I have a driver's license
number and a lot of time that's used as my unique identifier. Instead of a
social security number, somebody will ask for my driver's license number.
we don't have selective disclosure and we don't have unlinkability in MDL.
Correct.

Greg Bernstein: So, phone home is the worst because that's real time
tracking, but we still have the potential for somebody tracking you.
Correct.

Kim Hamilton Duffy: Yeah, I can talk to what I know about it. So there is
some hardcoded selected disclosure over 21 as a hardcoded claim, not like
PBS plus kind of selected disclosure and if there's a server retrieval
token the guidance and I forget how strong it is from the ISOspec is do not
reuse the token. So the NDL would have to request it fresh every time. So I
suppose that's intended to minimize verifier correlation but still the
concern about if it's all going back to the issuer anyway who can build
this graph and then potentially package resell it or if other kinds of
correlation there's many methods about sort of your device itself that
could be used to rebuild that picture.
01:00:00

Kim Hamilton Duffy: so the tlddr of that is basically I think that there
were some nuances that sort of wink at those concepts but don't really pull
it off in my view.

Greg Bernstein: Thanks.

Harrison Tang: All right, we're at time, but any last questions? And then
as there's a lot of comments about OID4 BC kind of u designs. I'll try to
get someone and invite someone for open ID to kind of lead the discussions
on that. Right. Thank you Timothy and thanks everyone for attending today's
great discussion. This continues to be a amazing topic.

Steven McCown: Thanks everyone.

Harrison Tang: So I'll try to line up more discussions on this topic in the
future. But thank you. Thanks a lot. Have a good one. Bye.
Meeting ended after 01:01:47 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*