Matthew: Can we bump this to next week?

Lola: Yes.

Lola: Looked at that this week...

Martin: My view is unsatisfied, simply because there is no spec. There might be other reasons for that, but I can't tell.

Marcos: Coincidentally, I have the spec text now on a branch. That fills in most of the blanks. There is no consensus yet on some of these parts, so these haven't landed in the spec yet.

(Marcos walks through things for https://github.com/w3c-fedid/digital-credentials/pull/306) That shows a picture of the architecture and the new "coordinator" role within the user agent, which manages access to the wallet. Then there is the whole formats side of the protocol. These are somewhat out of scope for the API; these dictate how you interact with different credential formats (mDoc, openID, whatever). The reason that isn't there is that we are working through the details and the algorithms and trying to reconcile that with implementations. Lots of reasons for not being satisfied.

Lola: We should hold off until everything is added. Also, the explainer is not an explainer: that links to the intro section, but the explainer doesn't cover some of things.

Marcos: Alternatives were custom URLs, which is in another document.

Lola: It's not clear. The explainer is not in our design-review issue.

Marcos: https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md should cover most of the explainer topics. ... we've been moving stuff from the explainer to the spec as the spec is filled out. So that things don't get out of date.

Lola: Should we wait?

Martin: I'm still concerned about the formats question, which is far from being resolved.

Matthew: Can wait.

Ehsan: I have an issue related to the no papers document with respect to how the API operates.

Marcos: It would be good to have something about formats to take to the working group. Even if the API shape is there, the formats would be good to take there. There is also privacy/security and the working group put in a lot of work recently on that. Would be good to see if there are things missing and set expectations.

Ehsan: Raised a question in the private brainstorming, wanted to clarify if there's any kind of counterfeit document.

Marcos: That's outside of the API scope. Not something that I can answer.

Lola: Is this an early design review? Or a step before release?

Marcos: Barely baked. Not much that can be changed, Credential Management API handles most things. Pretty much set in terms of inputs and outputs. Very simple API, even though it does many things.

Hadley: Are you concerned about the API?

Marcos: I'm concerned about what happens outside the API. How it's used, or how often it's misused. but we've done what we can to mitigate that. The EU wants to use URI schemes, which is even worse. So we're trying to fight back. This is the best of worst solutions. Made it very clear in the WebKit position that this is concerning. But at least we as the web community have a say through this.

Martin: Do you know how issuance works with this API? Does it require back-channels?

Marcos: I can issue the credentials, I'm the driving authoirty app, and I have this capability to issue. I'm a website, foo.com, and I am authorized as a website to allow the requesting of the issuance of drivers licences from state A, B, C. Then there's a wallet (native app) that is able to pick that up. But the request being signed goes to the website. Native app handles the issuance.

Martin: So it is going around to the wallet? The spec doesn't say that. Does stuff a GET method isn't allowed to do.

Marcos: We haven't implemented it in WebKit, do I don't know how it works. There is nothing in Apple's platform that allows for issuance.

Martin: Some protocols allow to interact with the TPM.

Marcos: There are some protocols that have those details, but they are not in the spec.

Hadley: Where is this going to be specified?

Marcos: Requesting part, request to create, is specified by us, but not the format, just take input of a particular type. How issuenace happens and the format of it is part of ISO. Defines all the steps needed to create a driver's licence, that is cryptographically approved by some authority.

Hadley: Seems weird to separate those, across W3C and ISO. I know some governments won't rely on non-ISO standards (which is a separate problem), but I'm concerned about that fragmentation.

Ehsan: Did you have a look at the Digital Credentials API session at W3C? If you don't have the notes, I can forward them to you. My concern is very much similar to what Hadley said. It's concerning that regulators use this pattern and don't trust browsers. What is your take on that?

Marcos: The OS doesn't issue credentials, the browser cannot do it. Only the wallet can issue credentials. And that wallet usually comes from a government or a wallet representing one. In Australia, there's a private entity (Bick Roads) that represent the driving authority in Victoria. The app has my driver's licence…

Martin: They've privatized this?

Marcos: Yes. This tells the OS, I have a credential and give that to the website. The website allows pulling in something that can be used to create a driver's licence. Only the issuing authority can create it. Cryptographic things take place to make it happen. If you watch my W3C presentation, it mentions the entire workflow.

Ehsan: Can you only use MDocs?

Marcos: You can only use ISO/IEC 18013-5, e.g. for driver's licence.

Hadley: How to proceed?

Martin: This is not fine, until you have something in the registry that can be interoperabably implemented. Need to dig a little more. I think this can be fixed.

Lola: Do we want to add this to the F2F agenda?

Martin: Seems worthwhile.

Martin to add this to the F2F agenda and to run the session during the F2F.

Martin: Where do we maintain the agenda?

Lola: Don't have one yet, will prepare.

Hadley: Feel it needs more than 15–20 minutes.

Martin: Rather expect this to be 1.5 hrs. Marcos should give us the nuts and bolts in 20 mins.

(Discussion if this is a good use of time.)

Hadley: where are we on this?

Martin: no progress from me.

Marcos: on the WG, we had discussions on the basic model. We are blocked by different arguments on different items, including interaction between APIs. Different suggestions. It is tough.

Hadley: what does it mean for TAG?

Martin: last time we discussed, we asked for some clarification. If it is blocked, we can come back to it.

Hadley: is it helpful if TAG does it?

Marcos: it is good if TAG looks at if it is a sensible architechtural machinery that is required.

Hadley: TAG response: these items are missing, and second: ...

Marcos: I could ot attend WG last week, I am hoping that would happen next week so we could resolve this.

Hadley: can Martin, Ehsan and Matthew come up with a comment?

Marcos: what does is it relate to?

Martin: my biggest problem is the lack of algorithms and not having anything in the registry.

Marcos: this is interesting discussion. There has been complications on registry over github.

Martin: I don't like their interactions. They had long responses, with no conclusion.

Hadley: I am still want to conclude on what to do with this. We can put comments, or officially ask to hold off and resubmit when you are ready.

Martin: my preference is to wait for the working group. But if you can ask something more concrete, we can act on that.

Marcos: I will put the comment on behalf of WG.

Martin: We were asked to wait, should be stop waiting?

Marcos: We have consensus to move on. Expect to merge some stuff in the following two weeks.

Hadley: Can we change progress to stalled or pending external feedback?

Martin: Think this is the sensible thing to do, if it could be two weeks.

Hadley: Need to know if I should put this on the agenda.

Marcos: Depends on how TAG wants to communicate with the Working Group, and about what. Architectural details? Usage of APIs? Depends how folks are doing the review.

… Thing exists in the world today, people are using it. How do we want to proceed based on those facts?

Hadley: Was under the impression that we were blocked by the WG getting consensus.

Marcos: Reality of the situation is that N number of sites are using the thing, pressure is different. It wasn't a week ago.

… Irrespective of the PR that is blocking. Will not change the view of the world.

Martin: I do want to have the discussion that Marcos talks about.

Hadley: Should we have it in the issue?

… Matthew, Ehsan, any thoughts?

Matthew: Agree we should have the discussion, but wasn't aware of the time scale. Can we cover it in the normal breakouts? Are we talking about this in the F2F?

Marcos: There's real concern now that this is deployed to the masses through one of the largest websites of the world. Not affecting other jurisdictions apart from UK, but that might change soon. You could image other sites quickly using this API. Now is the time.

Hadley: Options: 1) Start the conversation, 2) schedule an additional meeting, 3) put it off to plenary of F2F, 4) too late, nothing we can do.

Martin: Last one is not an option. Don't think we can get away with saying nothing. The finding may be all we say. We do owe people a proper review on this one. Think we don't only need the low level (UX etc.) but also high level review on this one.

Hadley: What do you need to do to get this review done this week?

Martin: This is not possible, next week… maybe.

Hadley: Still worth doing?

Martin: Would be surprised if we can be done in two weeks, because of the nature of the work. But it is a much more reasonable timeline.

Ehsan: Do we have an idea of what we want to say?

Lola: Think we want to have the four of us discuss this separately to brainstorm together. Martin, you have a lot of expertise, but it shouldn't all be dependent on you.

Matthew: Two questions, 1) unclear if we should take the extra material into account that Marcos talked about, sounds like we should to it, 2) I think the review of no papers, we need to rename the repo. Should we publish it soon?

Hadley: Re 1), The link is in the comment. WG is still getting consensus, we cannot assume that yet.

Marcos: It's a very thin UX-related change, has no bearing on the rest of the thing. Wouldn't worry too much about this one. Not architectural.

… I'm available to the reviewers to join whatever call as an editor. Might accelerate things, even though I might be biased. I'm very sceptical myself.

Matthew: Timeframe for publishing the finding? Ahead of the F2F would be good, and think we should rename the repo, but don't have a suggestion.

Hadley: Thought this task was with Jeffrey.

Martin: Suspect we will make a publication decision in Hong Kong. Would be good if we had it sooner.

Marcos: Think it would be worthwhile to put it out in the world.

Martin: Would be comfortable if the rest of the TAG agrees with the points raised there.

Hadley: Martin, think the decision falls to you.

Martin: Want to see if everyone approves the publication. Think we're getting close to that point. Might be easier in Hong Kong, but if we could do it sooner, we should do it sooner.

Hadley: We also have a plenary next week, if you want to present the points?

Martin: Would be much happier if people would read it. It's not that long. Plenary sounds good. Hope it to be done for the plenary, a "please read it" pitch.

Hadley: I will make sure it's on the agenda.

Lola: The API doesn't have an explainer. They put what have been the explainer text in the spec text. Do folks feel they need an "alternatives considered" section?

Marcos: There is a whole document on the alternatives, and that's the custom schemes one. There was no time to come up with other things. But they were designed over the last couple of years.

Martin (chat): There is an explainer, and there is such a section. Thought it was pretty reasonable.

Marcos: Official explainer is at https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md

Martin: Don't think explainers need to be maintained in the same way. Good thing that the explanation moved to the spec and is kept up to date there.

Lola: I noted that they should flesh out the explainer in the spec, but I haven't finished otherwise. Matthew?

Matthew: I noted quite a bit in the private brainstorming thread. There's a list of things we haven't brought up before, and a copy of an old thing. The long section is varying levels of importance, but it's all worth asking. It's a reflection of the fact that as Martin said, there's a lot of detail missing. Some is suggestions that we should put prominent notes pointing out to other documents. One typo I did a PR for, so it's not in the list anymore. Feeling on whether we have rough consensus that these things are worth mentioning? Martin was saying that the vibe is that these are things we should be asking.

Lola: On point 3, "Does the verifier get any information on the wallet model? like some digital credential are to be held in government official wallets so it might reveal the citizenship of the user to the verifier as side channel? (e.g. through 'the data member' request data to be handled by the holder's credential provider, such as a digital identity wallet.)"

Lola: My sense is that the verifier and issuer don't know anything they don't need to. Verifier shouldn't know anything about the wallet?

Matthew: In theory yes, but say your gov't issues stuff comes from a particular wallet that only holds that stuff. Does that leak somehow? Credential has to come from this kind of wallet, so this person is German?

Lola: When I read the spec, I thought the answer was 'no'.

Matthew: They expressed a desire, but we're wondering if the tie of a credential type to a kind of wallet makes it clear.

Jeffrey: I think the identity of the issuer is necessarily exposed and reveals things like "I'm German". But the identity of the wallet could be private in other ways, and if the spec doesn't guarantee that it's kept private, that's something we should ask them to guarantee.

Lola: Think there's no harm in asking the question. Maybe they'll just need to be clearer.

Jeffrey: This is a good list of things to ask them. We should flag that it might not be complete.

Lola: "16. Accessibility considerations: UI isn't specified, but it would be vital to ensure that any info presented in a non-text way has an alternative. So far I haven't seen any such info though." -- Is that the spec's responsibility since UI is out of scope?

Matthew: We know that UI is out of scope, but if there's the possibility of showing non-text data.

Jeffrey: Photo?

Matthew: Non-text data needs to have an alternative, probably text-based. Might be that the answer is that it's not up to the spec since it's format-agnostic. But then it should be a requirement for protocols to be allowed in the registry. Definitely also author/issuer, but probably schema too.

Jeffrey: Do make it clearer, since you're expressing a very technical requirement on the data format that expresses the credentials.

Matthew: I'll do a pass with the above updates, will post a draft comment to brainstorming.

Lola: This list is long, and everything present should be present. Martin might add things. Should we do one long comment? Think we shouldn't merge the two.

Jeffrey: I think we shouldn't wait for Martin's review, and should give them the feedback we have when we have it.

Matthew: Martin's comment might be more architectural, while mine is more a spec review.

Lola: I also plan to do a review, and I'll avoid re-posting things that aren't in Matthew+Ehsan's review.

Lola: Matthew and Ehsan have a nice list of questions. I haven't given this a lot of time.

Martin: This is not an implementable spec.

Lola: Marcos, is there time pressure on this spec? Can we table until Hong Kong?

Marcos: There is no time crunch on the implementable question. The pressure is with respect to sites adopting it. ... We should get the no-papers (whatever it is called) out. WaPo put out an article on the technology, with some inaccuracies, but very interesting to see what people are saying. The no-papers document gives a good technical foundation and explains some of the dangers from a few perspectives. ... At the same time,... With Google, they are doing ZKP stuff with adult providers. At least they can't identify people (in theory). Some sites see a drop in visitors when they comply, others - who are ignoring the law - see huge increases in visitors. This doesn't change content consumption habits. VPNs usage skyrocketed. This is important to be out there, because it does provide a knowledgeable perspective on the technology and the possible implications.

Lola: Might agree about unimplementable. Should we wait until after Hong Kong. Not going to change much in the meantime.

Marcos: Lots of difficulties getting algorithms from the WG. "Why can't we just list what it can't do?" That's not how computers work. Maybe we'll have more in ~two weeks.

Lola: We can discuss what to do F2F.