Skip to content

Latest commit

 

History

History
1322 lines (1056 loc) · 110 KB

agenda2021.md

File metadata and controls

1322 lines (1056 loc) · 110 KB

CHRISTMAS BREAK - 29th of December

CHRISTMAS BREAK - 22th of December

Agenda - 15 Dec - US time

Transmute and Karyl comes and talks about what are the interop views they are selling to investors to We are inviting Transmute with Karyl to talk about their last funding round to discuss how investors are triggering on their case and what level of interop is sold to the investors. They will join and sharing that journey with us in the scope of how interop is valuable, it would be great!

Agenda - 8 Dec - EU time

Slides: https://docs.google.com/presentation/d/1ki2VMtW1yZnWlomyeoYCIfrkLhb2Qb7Kb5sNQOiLYnY/edit#slide=id.p

Dmitri Zagidulin will come and start discussion a common QR-code initiation. See where that shall go and how it can work

QR code limitations are starting to drop of. Thanks to certain events we recently had and technology improvements.

Size limitation is still there

4 ways to share a credential VP, depending on if it is offline or online. Is it an either or, or can we switch between them.

Microsoft introduces some new potential ways of looking at sharing, and will be shared after meeting. WebShareAPI, Microsoft Cable project - https://docs.google.com/presentation/d/1ki2VMtW1yZnWlomyeoYCIfrkLhb2Qb7Kb5sNQOiLYnY/edit#slide=id.gf8d555be24_0_23

Deeplinking

Universal App linkes or custom protocol schema. We have two deeplinkg actors, iOS & Android.

But there are multiple fallacies here, that comes down to the user on boarding. And how to make sure that we are protecting the user at the start, versus keeping it sleek.

Option to consider

Agenda - 1 Dec - US time

Cancelled

Agenda - 24 Nov - EU time

Recording: https://us02web.zoom.us/rec/share/T56nah0ObZFk7J5eck4bu9A_qzJDvmGW7Ze9bgjsG_A8OJ2rnyedjkJqQAfXOUlB.yo0_Kyo0lUQ3e2Z4

  • We want to be able to be nimble but still showcase that this group provides value. The success criterias are great!
  • Review "charter" and make it lean to reflect a more agile form. In the sense that we cannot predefine what we are doing now. Because the ecosystem is everchanging and new players come in.
  • Showcase current action points and direction to go and get some discussions and thumbs up.
Summary

Do we want to define an interop profile for the community? How do we attack this task? We want need a clearer map

We have drafted a shorter cleaner version: https://docs.google.com/document/d/11EKZZ0sSqOrXmdtDEtts4OrIVtQRSLB8mA3VxFLFgEw/edit inspiration from the older one https://docs.google.com/document/d/1a01GQVtZB7tDVcm9avS8zuYPHQzEEDtTOEh4Bqu-8Bs/edit

We will announce and get feedback from the mailing list and slack!

Agenda - 17 Nov - US time

EU meeting recap and action points from the outcom of that meeting

Agenda - 10 Nov - EU time

This week we are getting a visit from the German community and hear how they have gone about interop. This conversation started during IIW and has been pulled through to have a introduction in DIF interop, and see what we learn and take from their approach. This meeting is on Wednesday, 10th of November, Europe time 3PM. Have a look how that looks for your timezone here: https://www.timeanddate.com/worldclock/converter.html?iso=20211104T140000&p1=137&p2=179&p3=187&p4=44&p5=28&p6=22 Or just add the DIF whole DIF calender to your calender: https://bit.ly/dif-calendar Look forward to seeing you there, I believe it is going to be a great introduction!

Presentation from Hakan, Andreas and Eugene

Questions

More questsions was asked in the recording, have a look at that: https://docs.google.com/spreadsheets/d/1wgccmMvIImx30qVE9GhRKWWv3vmL2ZyUauuKx3IfRmA/edit#gid=2146749098&range=C82

Tests? How have you guys gone about it?
Not yet, but it is one of our next priorties. Taking inspiration from the Aries test harness and how that should and could work.

What is the core connector for interoperability?
One profile that works acrosss the consortias would help to begin with. Instead of multiple profiles that did not work together.

How does this work with EU initatives? Meaning all countries should deliver a wallet that is interoperable
Not afraid not exctied, very netural on what will happen. Look forward to see what is going to be in the toolbox.

The interoperability matrix they are working on
https://docs.google.com/spreadsheets/d/1R0Y4ec1KVYErkcEgC3Qww7VR4CsCY2Lv2Bt-gfryEdw/edit#gid=1316375328

Agenda - 3 Nov - US time

Rechartering, take inspiration from this: https://www.notion.so/dif/HOSPITALITY-TRAVEL-SIG-242105321e1747f8bce776bf634a55b3. Pr this older PDF. Since interop group is not IP protected and our current charter is just a draft: https://docs.google.com/document/d/1a01GQVtZB7tDVcm9avS8zuYPHQzEEDtTOEh4Bqu-8Bs/edit

Balaz proposed to rename the group to something else. (WG name is confusing for many companies as this group is not IPR protected) Lets hear from Balaz on what is thoughts are to get a better understanding.
Suggestions are: Interoperability (X)Cross Community Group.(WG name is confusing for many companies as this group is not IPR protected) Where do we need to rename things?

Questions

How does it all fit into the other groups? The SIGs(Health and travel) and discussion groups(Africa and Asia)?
IS this the place to build and discuss test infratructures for interop?

Agenda - 27 Oct - EU time

No agenda, cancelled

Agenda - 20 Oct - US time

Internet Identity Workshop Recap, with the focus on interoperability. Did anyone hear anything really cool about interoperability during IIW? Anything worth taking notice of?
@DW (Ping Identity) - do you have a summary of what interests came up for the interop group? Talk abit about the future of library polooza if time allows.

IIW Highlights Adrian: Two orthoganal axises - KERI - innovation and thought about security and privacy from an academic perspective but completely ignoring everything that has gone on for 6 years. DIDComm and relatives - that keep plowing ahead in a series of protocol decisions that are self referential. This is where at - now we just have to get to agree. Some people think we are already "done" KERI camp working from first principciples and do right. Noted they are not talking to each other. Darrell - premature interoperability premature standardization - we are not "there yet" which is why we see KERI DIDComm trying to align - governments taking Hyperledger Aries/Indy going to market. Interoperabiliy is not a term that is well defined. Overall good news - everyone agress we are heading in the right directions - How key rotation happens. Answer that happens in time. DIDComm world moves ahead - executable working code - those executing running along in the same direction. Describes why it is really messy. (Lets find a link -to Darrell's session)

Who is implementing KERI? - who is impelmenting - KERI is implementing - GLEIF

Sam: Seemed less rushed an panicy Fewer sessions that were more engaged in. Mike Ebert - opener question what proud of what afraid of. Where things are? Thinking a lot about IIW kinda used to be about Federated Identity - now about SSI the federated ID people less interested in the conversation. KERI - DIDComm not talking to each other - the appropriate form is to talk to each other in DIDs. Not opposed to KERI. Related - No one has throughly plugged them together.

Vitorio talk on end of day 2. DIDComm - OpenIDConnect tension exists and draws out important things. What is it important that it draws out - do they realize the vision of DIDComm - bigger then passing credentials. Helps to draw out the assuptions people are starting with. A lot of things about identity - are things about people = credentials. Holders some times involved not always involved. Things about me - DIDComm is communicating "with me" not about me. Distiction about the two. Do I use DIDComm or do I use SIOP - not accurate to pit them against each other. They are in some areas - there is a lot of get along-ness and likely path to get along - can go from OIDC-SIOP -> to DIDComm connection. Todd: The last two IIWs I have attended fewer of technical sesisons - role not working with software developers- more to choose from on the non-technical philosphoical discussions. Try to listen closely to what people are saying one of the big challenges is adoption - and getting outside this community- good to see new people - they are very enthusiastic - how does it help everything move forward. A lot of technical barriers - Sam & Sam - understand the competing agendas of the various protocols - at the end of the day looking at the consumer side- who is going to be using it. Post listening to recordings. What do we need to we get the word out.

ID2020 - felt that it was less technical then in the past. Looked at calendar and daily agendas. working with NGOs - very interesting - open to broader crowd.

Adrian: Another impression - that the reality around SSI are actually to start to come to light. After a long period (2 years) of Kymbaya. Given by focus on DHS and closely related projects and interop from there. What I am seeing at this IIW and like 4-5 really key issues coming to light.

  1. LD vs JWT -> seemed to have a collaborative solution. Driven by MSFT VCI.

Data Rights Protocol org working with Sandy Pentland - building on JWTs 2nd genration identity. YouTube

They imagine - 7-8 different startups class of businesse act as service providers to consumer businesse that collect data - how are these service providers gonig to manage GDPR/CCPA data rights? approach from the commercial perspective - said from the beginning - they said there would be a 4th party involved where individual is proxied by an agent relative to a service provider (daza greenwood) working with credit unions and cooperative model and this includes it.

5 specific end points - Make this commercial offering - they can go to us as the service providers to verify identity of people and manage their data rights.

Class of service providers selling B2B to and then - but they are there to offload the job of mandated to GDPR/CCPR around data rights that affect these businesses. In HealthCare we had this same thing service providers. MSFT build whole msft health strategy on it working properly.

  1. Issue of Fedreation - OIDC google app/mozilla/apple formal objection to DIDs - peace is not made with federation

  2. Trying to square verifiable data registries of various sorts - roll of private blockchains and role of hyperledger

  3. custocial wallets/agents - Diwhala/Kiva - work with custocial wallets - seeing fragmentation. So much of what has been happening - every action is an authenitcation action like a FIDO-secure element - delegation to an agent - custodial wallets. "SSI we" has been living in tihs lala land of our own making having to face the market reality.

Keith: hear about things about VCs being in production - I don't see it. Was on a call with an analyist. Am I missing something. People in production? Is there a big use-case that I'm missing.

Adrian: VCs are clearly inevitable - what is not inevitable - is the subject identifeir and the schema's for VCs. That is why there is a duality between mDL and W3C standard track stuff. Education folks driving themselves nuts - running ragged - VC SSI model. What is driving them crazy - what they have done with Open Badges and tryign to include SSI standards into their market - where they service providers are institutions (and people) purity difficult to adopt Hyperldeger and DHS model. MSFT is fighting the good fight - they are in the identity hub/secure secure data storage - we have a band of catholicism that is not open to the relaities on the ground from the other perspective - IMSGlobal CLR - OpenBadges willingness to move towards VC model - we didn't want to be in a world where we are implementing all of the above. they will happen. How schema and subject identiifers. The most interesting move away from schema's towards types. I didn't see a lot of negativity. Who are the verifiers - them is us. They educational institutions accept credentials from other educational institutions.

Guardianship - Signing relesases and getting inforamtoin directly from the institutions. They want the credentials directly from the instutions. They don't have the same prolem of "calling home" anything that complicates revocation.

Agenda - 13 Oct - EU time

No call due to [Internet Identity Workshop][iiw]. Look at notes for potential sessions.

Agenda - 6 Oct - US time

Items

  • Library polooza followup meeting
  • 5 min for IIW dicsussions, anything we need to discuss prepp for IIW

More info

Polooza

The second-part followup to the “Library interop-polooza” discussion two weeks prior, which had participation from Aries, MATTR, Spruce and Veramo.

Agenda working doc is here for history keepings: https://docs.google.com/document/d/1wWl442DQK0dHhtL8HHsbdtbpMxRL-_mjCPpb3RDQo3M/edit#

IIW

We should present the work going on and get more people to engange in this future work at IIW. So lets think about a session.

How do we make sure this work differentiates from the whimsical diagram, or atleast stays up to date? https://whimsical.com/decentralized-mapping-exercise-clustered-LJJ1rizUQcYcL7MUwqWbTn

Previous meetings

Agenda - 29 Sep - EU time

Authentic Data & KERI and Certificate Transparency - Dave Huseby organized by Kaliya

Agenda - 22 Sep - US time

Meeting postponed to a later date

The second-part followup to the "Library interop-polooza" discussion two weeks prior, which had participation from Aries, MATTR, Spruce and Veramo.

follow up - Agenda worked on here. Will be posted when last comments are resolved: https://docs.google.com/document/d/1wWl442DQK0dHhtL8HHsbdtbpMxRL-_mjCPpb3RDQo3M/edit#

  1. Introductions
  2. Stack diagram, any missing layers relevant to interoperability? https://docs.google.com/spreadsheets/d/12_03m8QU1J0VaskBEnA97aUXz38kSTskvM7DwfSAPFg/edit#gid=0
  3. Structured credential data model w3c/vc-data-model#788 (comment)
  4. How invested are people in getting interoperability?
  5. What is the high level roadmap for interoperability?
  6. Where do we start testing on this?
  7. Can we carve out a small piece that everyone feel they have in place to start aligning interop?

Agenda - 15 Sep - EU time

Mozilla objection we talk about what that is, what are potential ways forward and what the DID WG thinks about this Brent Zundel comes and shares.

The objection can be seen here: https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html

Why public vs private objection: Mozilla pressed the wrong button.
Formal objections happen, and response should come from WG group chairs.
Not requiring specific DID method: out of scope in charter from start. Compare to HTML img tag - no specific image format required
Having DID document shows interoperability
Divergence: comparison with 300+ URI schemes, 78 URN schemes
But underlying common data format
About centralization: Cannot define misuse of the technology. But have rubric to facilitate subjective evaluations.
About multiple data formats (JSON, JSON-LD): potentially valid complaint, but inappropriate timing. We could have just picked one - the group had hours and hours of conversation about how to and whether or not to do it. Objectors could have raised this 8 months ago and we could have officially addressed it. Cannot do anything about it now except note the concern and apologize.
Proof-of-work (PoW) blockchains vs. ethical web principals (EWP). EWP is great but not recommendation / normative guidance - don't reflect consensus of W3C and not part of the process - are a set of what one group thought were good ideas. They are indeed good ideas, but there is no requirement that we adhere to them. Encouraging low energy consumption, attacking existence of DID methods requiring on PoW blockchains. Assume PoW is a horrendous waste of energy: begins with statement as though it is fact, but a lot of people don't agree with it.  Wanting the DID WG to make a formal position about all PoW blockchains and enforce that no PoW blockchains be allowed to support the back-end of a DID method... We can define the technology but not how people use it. That is assuming PoW is as bad as claimed. Complaint asks us to stick to a document that is not official. DID Spec does not require verifiable data registries, blockchains, distributed ledgers, Bitcoin, Proof of Work - not statements about these things. It's possible we could say you shouldn't do that - but the WG doesn't feel it would be appropriate to try to normatively define what a DID method is and isn't allowed to do - especially in light of the ongoing debate about PoW - if it is the only way to pay for the level of decentralization that some security stories call for. We would like to put something in out implementation guidance saying you should be aware of these concerns - but we may not be able to come to consensus on it. May be a red herring... some of the objectors in the past have publicly supported blockchains that use PoW.
The public statement by Mozilla names other groups. Microsoft did not formally object to the specification - they joined the WG and were relatively active in it. You can't assume what the other formal objections were based on the contents of this one. But they do echo those points. There were three formal objections, all of which made the same sort of set of points. Mozilla's was the only one that they pushed the wrong button on.
What to do: what DIF and ToIP have done: statement of support for decentralized identifiers. If people say "it's dead now", point out that it's not - has objections, ongoing debate. In our opinion, the objections don't have a leg to stand on. Combating the FUD. We'll just have to live in anxiety for a while.
Snoore: Are there any anxiety-removing elements that one can do?
Brent: not really. Process doc is explicit about there being no time limit on the director's deliberation. Call for Review for when we went to Proposed Recommendation ended. At that point, 3 formal objections had come in. Now we have this undefined period of time - takes s long as it needs to take - for the director to hear both sides, gather evidence, and learn about things. That process, unfortunately, takes a long time. We at the DID WG would really prefer if the director had gotten on the phone with us immmediately - and said, these objections are baseless and here are the reasons - we really would have liked that, and it would have been done. I hope in next few weeks, chairs of the WG will get to meet with the director. Then we'll find a time when we can all meet with the director, and hopefully get a decision. THis is probably going to take at least another month, and it's going to be uncomfortable. We can reflect on the fact that process-wise, we have done everything we were supposed to - and we can back that up with documents. Not much else we can do.
Snoore: Hours of talk on this point...?
Brent: The JSON-LD one. Our actually only official face-to-face (F2F) meeting was in Amsterdam. It was January 2020. The bulk of conversation was around how to deal with these two very similar but subtly different representations of a DID document. The conversations that we had while in Amsterdam were what gave birth to the "abstract data model" that we introduced in to the specification - which for a time gave birth to the idea of serializing into CBOR. Unfortunately, the CBOR serialization wasn't able to mature well enough to end up inside the spec - but it was there for months. Not a conversation we have had, but a conversation that if the objectors felt was really important to have, they could have jumped in and had it with us.
Snoore: Other questions?
Kaliya: You are responding with a lot of process points, which I agree with , but is there also responses about the technical - not just about the process - that are actually trying to rebut the technical things they are saying?
Brent: We do have some. With the requirement that we normatively define a number of DID methods, apart from being completely out of scope, the question is then, which 3, 2 - which set of DID methods would be most appropriate for the WWW to say, "these are the official ones". That conversation has kindof been going on in the background for a while. e.g. some people think we may be able to get agreement to define did:key, did:web. But then there is the irony that if you have did:web, you are probably relying on DNS - not really very decentralized. Beyond that, nearly every other DID methods relies on some particular distributed ledger or blockchain - and they all have different security characteristics, different requirements on how we resolve them. For the commmunity to come together and say "this is the one" that we all agree on well enough to define normatively - on a technical level, what they are requiring it may be impossible for a QG to come to consensus - not only the DID method specifications themselves, but on which ones to start with in the first place. The other rebuttal there is, are you actually going to participate this time around? How dare you suggest there is more work to be done and you go off and do it? That's not how process works, how specifications are written. That's "go find a rock" - "no that rock is too grey" - "no that rock is too small". If there are members that have opinions on what ought to go in a spec or not - or ought to be worked on by a group or not - then the appropriate course of action is for that member company to join the working group and participate. For them to complain we haven't done the work, and also not participate in the work in the future, really means that, because they haven't claimed that we are doing is harmful in any real way, they really can't back up the statements.
Like at DIF, if people want to create a work item, if someone outside the WG says, "hey C&C WG, you should really work on X, Y, Z" - C&C WG would say, "good to know, would you like to join us, submit a work item and get someone to work with you? 
W3C also recognizes it as an absurd notion - to say a WG should do something, and then disappear and not participate.
Chris Kelly: I get Kaliya’s angle… it seems youa re trying to circumvent the technical arguments with the process arguemnts… but it’s not the case… the charter has been fulfilled and delivered upon. If it shold have looked differently, that should have been clear from the start. It’s too late yo move the goal post…
Brent: It’s possible to disagree on technical solutions. “We think it should be JSON”, “We think it should be JSON-LD”… it’s harder to disagree on Process. The reason we are basing everything on a process argument… They can claim that we don’t have interoperability… But we can, according to the process, show that we have done everything we are supposed to do to show interoperability. We did what we said we would do in the charter… at least two implementations for each normative statement. They are saying “real interoperability requires more than that” - like Chris said, they are trying to move the goal posts.
Chris: Also important to remember that the standards track is a long and winding road, but not a definite endpoint. v1. Hopefully will mature… But having a clearly defined start point is important.
Brent: Couldn’t have said it better myself.
Kaliya: great.
Snoore: Has this objection shaken other groups’ reliance on DIDs?
Brent: At first yes, some groups not familiar with process. Thought “Oh, it’s dead”.
Back up… it’s not dead, not even dying.
Some things need to be addressed - or even how appropriate it is to bring up those things.
Then it goes to the director. We rely on process… pretty unlikely it will not be a rec. Possible it will be delayed. Very unlikely to disappear.
Snoore: So if back to draft… two more years?
Brent: It’s possible director will agree with concerns and say yes, need to
recharter for two more years. But conversation in advance of that decision will need to be, exactly what does the new charter look like - and are you going to participate. It’s one thing to say we have concerns and go back draft…
… We’d love to have Mozilla on board. We would like to engage with others.
… No valid reason we shouldn’t make it a recommendation and then move forward.
… If you want to participate in defining scope of work, you can do so.
Snoore: thanks for sharing. Core foundation for a lot of things. Good to know you guys have it under control. Interesting times.
Brent: For me the worst part of it is the waiting. I’m confident in what the resolution will be, and what the next steps for me to take will be - but there are steps othe rpeople need to take before I can take those - and I’m just sitting here waiting for the next step to have - and it’s oncomfruatebl. I appreciate the support from DIF and this group in particular.
Snoore: We appreciate your work.
Chris: I also want to thank Brent for taking us through this. This is the process. It’s important people refute statements about it being the end. We don’t need to be making big statements - but it’s important to remain positive, say good statements. Process is ongoing, we feel positive about it, believe in our work, watch this space.

Agenda - 8 Sep - US time

Library interop polooza with Aries, Mattr, Spruce and Veramo

  1. Aries presentation - aries protocols and test suite
  2. Veramo presentation - work done towards did com and potentially credential exchange
  3. Spruce presentation - unsure what would be different from veramo?
  4. Mattr presentation - Talk about how they tackle introp in SVIP and participation of VC http api

Announcements

Juan (Spruce) on new interoperability efforts:

Presentations

Aries by Stephen Curran

Aries: introduction, implementations, interoperability and test harness

https://docs.google.com/presentation/d/1QzE0wBSZyYSCcwbU6huEDfspRKqnokE2WEwi-RitHVc/edit?usp=sharing

Interop test suite information at https://aries-interop.info

  • Biggest concerns w.r.t interoperability getting more implementations to participate in interoperability and publish results

Veramo by Oliver Terbu

Spruce by Juan Caballero

Web documentation at https://spruceid.dev/docs/didkit-packages/cli

  • command-line and HTTP API tooling for various decentralized identity mechanisms
  • focused on LD tooling first

MATTR

Update on DHS/SVIP plug-face

web-based documentation at https://learn.mattr.global/api-reference/v1.0.1

Goal is to enable primitives to exist to compose for use cases like interoperability testing

Layers needing interoperability

Model from Oliver:

  • VP/VCs -> Data Model, Crypto (Which curves? Do we need to touch upon this now), DID methods
  • VP request protocols (aka present-proof etc) + Data Model (e.g. Presentation Exchange)
  • VC issuance protocols (aka issue-creds etc.) + Data Model (e.g. Presentation Exchange)
  • VC revocation

Questions to ask ourselves during layer discussion

  • What functionality have each library(company) implemented and tested and used?
  • What part of this layer interop is DIDCom solving?
  • What part of this layer interop is WACI PEX solving?
  • What part of this layer interop is PE exchange solving
  • What part of this layer interop is VC http api solving?
  • What part of this layer interop is the Aries protocols solving, Aries Protocols in general, the set of protocols in AIP 1.0 and AIP 2.0 in particular?
  • What part of this layer are the mentioned tools stepping on each others feet?
  • What part of this layer are we not seeing or mentioning where interoperability is needed?
  • Are we remembering that the same interop has to happen on a browser as well as a mobile phone? What layers need to be set in motion to have that ready?

Diagram of various kinds of credentials

w3c/vc-data-model#788 (comment)

Goal

Make sure that we are having the right efforts in place and we believe these efforts will move things forward in the right direction. Highlight where there might be missing efforts.

Appendix

Working doc: https://docs.google.com/document/d/1wWl442DQK0dHhtL8HHsbdtbpMxRL-_mjCPpb3RDQo3M/edit#

Agenda - 1 Sep - EU time

Summervacation back 8th of Sep

We want to spend some time as a new group, to regroup and get into orbit instead of full trusters into unknown space

Agenda - 25 Aug - US time

Summervacation back 8th of Sep

We want to spend some time as a new group, to regroup and get into orbit instead of full trusters into unknown space

Agenda - 18 Aug - EU time

Summervacation back 8th of Sep

We want to spend some time as a new group, to regroup and get into orbit instead of full trusters into unknown space

Agenda - 11 Aug - US time

Summary

Go the the CCG recording on Tuesday 10th of August.
Aries testing can be lobbied into be adjusted.

WACI v1

WACI v1 Introduction and where it is

WACI interop

We narrow the scope to focusing on the interop part of WACI.

We talk about testing
We talk about WACI, with an interop focus to make sure that we are getting where we want.
We talk about what steps is needed and highlight the efforts needed to get there.

Agenda - 4 Aug - EU time

Information accessability and collection

Information accessability

How do we make the information structure better and make all the info available easily. Such the https://identity.foundation/faq/ and the meeting notes

Information collection

How do we make it easier to contribute to and easier to have some editorial power turned on. Or is this needed?

Summary

Github might have issues, but it is becoming more easier to use. 3 issues Accessability, it is accessible in github Collection, a place it lives and has some gateway management Collaboration, Inline commenting is helpful, like put in a google doc with version control.

Potential steps forward

David, Chris, Balazs, Juan and Snorre meet for a meeting to discuss and painpoints related to the summary. Chris takes responsibility to setup meeting.

Topics coming up during meeting

Business models and self sovreignty problems

See chat and recording for discussions. We need win win win solutions Before last IIW there has been alot of research on interop problem.
We need to be able to move the credentials around!

Steps for further discussion

Join special topics session of IIW later today. https://iiw.idcommons.net/Business_of_SSI_Proposed_Topics

Other topics

Meeting time

Meeting times discussion. Are everyone happy with current meeting times? The A-meeting will not work for the european co-chair. Run a poll of who knows they will attend to find the geo areas we need to cover. https://timezoneninja.com/

Resolution

We will ask the asian working group to hear if there are any needs expressed to join the interop call. Based on that we will adjust times thereafter. Balaz will initiate that message and communicaiton

Agenda - 28 July - US time - Report from the W3C Federated ID Community Group

Heather's slides | recording

Agenda - 21 July - EU time - Updates on NFC support - Passport NFC demo from iGrant.io and DIDComm NFC update

  • Lal's Slides
  • George from iGrant.io will demo a new OS NFC library made for their data wallet
  • Timo from Animo Solutions will discuss the DIDComm-Bluetooth spec and implementer's experience prototyping asynchronous messaging over such a transport

Advanced readings:

iGrant Presentation

  • intro - NGI Trust ESSIF-LAB, Mydata Operators and Community
  • B2B offering - Data Intermediary
    • Data Intermediary (as defined in new EU DGA)
    • Auditability (and every txn covered by at least one data agreement signed in advance by responsible parties)
  • Demo
    • QR code --> base64 encoding of small JSON blob, not VC (as is the norm in europe)
Q and A session 
- Timo: how's data get from passport to app?
    - are you "proxy issuers"
    - we're working on a similar project, but we're having trouble verifying the passport data server-side
    - Lal: Yes to both!
    - George: We fetch the public key and copy it into the VC;
- Timo: But you check the signature on the data, if verified, put the data into a VC and ... who issues it?
    - George: Self-issued by holder; public key/x509 included in the data, consumers have to verify that way 
- George: open issue: selective disclosure complicated by needing full credential/data to 
- Value - add - binding envelope to data sharing agreements
- Pam: Full Audit? Allowlist? Fraud detection?
    - Fraud detection is the goal here
    - Correlation risk in full-disclosure?
    - Jan: Code of conduct/disclosure rules baked into the data sharing agreement?
        - Lal: Jan involved in ISO and Kantara standards on these issues
        - Jan: pre-existing Data Protection Impact Assessment has a responsible party's signature; see bullet #2 on the DDX repo for more info on these data agreements (based on Kantara /ISO 27560 consent agreements)
- Timo: OS?
    - https://github.com/decentralised-dataexchange
    - https://github.com/L3-igrant
- Neil: Scanning dependent on [OS-embedded?] NFC?
- Android and iOS have a lot but we had to do a little extra work to work with that; NFC not really standardized, big discrepancies across passport issues (doesn't work with Australia yet, for ex.)
- Timo: NFC and DIDComm - DIDComm want to support bluetooth and NFC, but still finalizing their requirements before spec'ing out
    - Bluetooth spec is stable and v1, but as yet unimplemented; NFC spec is not even started yet or implemented (including the issues you mentioned and )
    - Sam Curren: There's been some "wondering" about the capabilities offered - we're currently conceiving it as a one-way and read-only transports (//QR); two-way NFC (as in finance applications) feels more daunting and pending research
    - Sam: incoming Bluetooth and NFC DIDComm people should head to [DIF DIDComm for v2 work](https://github.com/decentralized-identity/didcomm-messaging/issues/222) and Aries for v1/implementable-today work
        - Sam: Data Agreement Decorator would be of interest to the Aries community!
        - Sam: Standardized mechanism for passing x509 signatures as you describe-- that's not an Indy-specific problem, that needs to be

Agenda - 14 July - US time - Report from the OIDF working groups with David Waite (Ping Identity)

Minutes:
  • David:
  • Back in the day internet identity = home on the intern. OAuth1 based on that. Self-hosting with TLS was expensive, compared to on HTTP, before it was clear that HTTP was no longer significant. Encrypted query parameters. Original OAuth model, for delegated API access. Original model: ask user for their password. Didn't want users to fall for that, so created system for limited delegation.
  • OAuth1 became IETF RFC. Work began on OAuth2 to meet needs of larger entities, have better interoperability, less custom crypto. It became difficult for OAuth 1 to have interop without testing against various websites, which might not have upgraded. TLS required on Internet: security model changed: where possible, security model became "just use HTTPS".
  • OAuth2 work fueled by large deployments. Google, Microsoft, Apple. Some of the original technologies for putting users in control were lost. Sign in with blog where do I type in my URL? Tech: dynamic type registration: website wants to interact with others without pre-existing relationship. Give URL to sign in field, figure it out on the fly. Set up relationship on the backend. With dynamic relationship, no trust - never seen before. Saying name: no reason to believe it. Aggregated and distributed claims - credentials from others sources - could be shared, rather than your personal blog's vouching for it, have some company do email verification. While could still host own infra, idea emerged of self-issued OpenID provider. Not self hosted but a native application or SPA to provide identity. Not internet-accessible, but still can participate in theis kind of ecosystem, authenticating the user and providing claims from pre-well-known/trusted authorities.
  • Work with DIF on extending SIOP (self-issued opened provider)
  • Pam: Last 10-12 years of professional career
  • Adrian: Keybase linking identities introduced trust missing in dynamic registration model.
  • David: Different kind of trust, can anchor with more sources of identity.
  • Original OpenIDI didn't stop blog spam, because spammers could host their own OpenID providers. Could block them, but no reputation. Keybase no way to verify email addresses because no social network, no way to collaborate and share information. Twitter/LinkedIn could hypothetically verified my employment history, Keybase didn't get there. Didn't standardize their cryptography beyond PGP until Zoom bought them.
  • Could see resurgence of it using Verifiable Credentials, putting proof of DID on social networks
  • Adrian: Difference between reputation and trust?
  • David: Good question, could lead to weeks of discussion on trust. Keybase: didn't expose a semantic model. I could personally decide if it's the person I want to talk to, as my personal trust, but doesn't give a foundation for semantic evaluation. That I use the same email address on different platforms might be enough to say it's a verifiable email address to a person, but never was enough to establish trust on a system. Always a human component to decide whether to accept data that may be acceptable via Keybase.
  • ... Here to talk about collaborations between DIF and OpenID Foundation, around OpenID Connect and specifically around SIOP. The way OpenID providers usually work is to have a set of negotiable rotated keys. Asserting individual customers... With SIOP, you do self-generated and pairwise keys - ephemeral, not rooted to anything. Like AuthN - doesn't prove relation with other things on internet, becomes Privacy-preserving: unlinkable. Can prove it's me: authentication.
  • Key rotation? Without losing access to systems? DIDs? Extend SIOP use cases to not just use self-generated keys but also use DIDs - referencable keys - to do key rotation.
  • Proposal on OpenID connect on verifiable presentations. Responses have own format for ... returning claims, id token. Could return VPs? From native wallet, progressive web app, or traditional hosted infrastructure - what if they could all use this format. Using presentation exchange. Majority of active work happening here.
  • Adrian: UMA... Bring something specific to your account to store separate as your identity...
  • David: Idea of user record in hosted application in single table demolished by authentication over the years. If have social providers, have many... identifiers, potentially access refresh tokens. e.g. Doodle login in with Google pre-check things. Have to store that information. FIDO, WebAuthN: authenticators registered with account: have to be stored so can use them later.
  • A relying party probably needs more, self-management of local identity on the relying party. For authentication... For recovery: one of reasons I think that "Sign in with Google" is so attractive is that I expect their Google account to outlast my account - so I don't have to do recovery. Ideally Google has an account recovery process. But puts you beholden on some other infrastructure as source of truth for users to get access. OpenID: without stable authentication, providers / blog infrastructures - move away from and lose access/relationship, no recovery. So it is more complicated but not more than WebAuthN or supporting multiple social networks.
  • Interest in using VP as recovery scheme. How? e.g. using American driver license, issued by state, and can present it. Even if no attributes, if it has a pseudonymous identifiers, it enables me to log in. If they have documents, those become verifiable.
  • If shared at registration time, becomes source of registration for recovery. If attributes shared at registration or any time after, issuer serves as verifiable source for those attributes for more manual recovery.
  • Kristina: if lose account and want to recover, lost trust relationship, restarting process, go through process costing companies a lot. If can use VP, that can help reestablish the trust relationship, can save calling, asking for secret questions, Mom's name, etc. Attempts to use different identifiers before, but in the end the providers were putting email in every transaction: became a correlating identifier. Now not needed, don't need email for recovery, can have separate identifier making it harder to correlate.
  • David: suggesting talk about this more on Interop channel on Slack.
  • Adrian: we now have Apple sign in with Apple, that includes a pseudonymous identifier for recovery instead of email.
  • David: yes, but there are caveats. Account recovery as general topic may be separate topic. Great topic
  • OpenID Connect for Verifiable Presentations: DID work is now a SIOP spec. Previous term: portable identifiers. For existing hosted provider, is there a way to include/assert DID ownership in challenge with other parties? Can combine so DID Auth is not a SIOP-specific feature but a general OpenID Connect feature.
  • OpenID Connect Aggregated and Distributed Claims: upstream credentials without defined retrieval mechanism. Potential overlap with Credential Manifest. Expand to also get Verifiable Credentials, to get into your SIOP-based wallet, to present them with various protocols. Decoupling: use OpenID Connect to talk with one party, use WACI-PeX with a verifier. Flexibility. SIOP v2: foothold for integrating all these efforts into a new version of SIOP. Focus on using that protocol on device. Verifier is native app or... Holder is native app or SPA. Possible to do cross-device exchanges... security?
  • Jeremy miller - extension with JOSE spec. OpenID traditionally uses JWTs over TLS. Can have an extension on JWS that supports selective disclosure, and zero-knowledge approaches like predicate approaches, like BBS+. Incubate in DIF Crypto Working Group, and eventually move to IETF.
  • Question: difference between empty VP and a DID? A DID is a referenceable URL that can lead to metadata. Some use cases want to have verification methods such that you can prove ownership of a DID. Right up the wheel well of original OpenID Connect.... have own ... services. VP: someone else could assert that I have a particular DID, but that presentation proves I own that DID, not someone else saying I do. Need to have nonces and ideally audiences, to know you are correctly doing a crypto challenge - otherwise, they are replayable.
  • Kim, Kristina: overview of family of protocols
  • Kristina: SIOP v2 a foundation: specific model: identity provider not big provider at Google or Microsoft, they are on our phone, browser, or PWA potentially. What does it mean for key management... How to use keys to issue... self-issued identity.
  • As provider that issues an id token, that's a place to look.
  • Initially in scope: how to transport VP. Larger demand on transferring VP using any model, not just SIOP. What if Google wants to send a VP on behalf of me, based on access token.
  • Two methods: either embed VP entirely in the id token, artifact that proves auth event. Or send back VP from user endpoint. Usually claims like address can be send from user endpoint, or directly. SIOP: devices cannot have endpoint/backchannel, so have to embed in token. Using term presentation: presentation happens when user proves possession of a VC, that's a VP. How does VC get into user's device in the first place?
  • Credential provider from Mattr. Defines new credential endpoint, from where you can return a new VC from the wallet, with proper bindings in place. It becomes important... wallet can prove in trustable ways... not replayable. Issuance phase: three big pieces. Another piece: conversation starting in Applied Crypto working group. Touched upon Selective Disclosure, Unlinkability, ... using JWTs.
  • Keith: what does selective disclosure in JWT VCs look like
  • David: Multiple approaches. simplest: decompose attributes, individually sign as part of a package.
  • Then maybe sign the whloe message. If you don't disclose the attribute, you still disclose the signature. Since can't recover (not like a hash), can verify attributes not disclosed, and verify did not pull out attribute from other message.
  • Or do like a Merkle Tree, document tree of individual attributes, just disclose the pieces you want: need to do some kind of salting, to make sure some field... like gender - there's only so many values it could be. If you have hash of value could rainbow tree and figure it out.
  • More options if doing pairing-friendly curve or zero-knowledge proof.
  • Kristina: using empty VP because no standard?
  • Kim: in funny world of SSI standards... interested in aligning with OpenID. Kind of a pattern: a Verifiable Presentation with no credentials in it, just signing over something with a challenge and nonce. Center consortium: using this for use case where subject=holder, they already have some relationship with some entity, they can authenticate in the usual means, but the issuer wants proof that they can sign a message with the keys corresponding to that DID. Pattern loosely called DIDAuth. Haven't looked at SIOP... self-issued, and DIDAuth happening in DIF... intersection. It wasn't clear, if we were wanting to use Credential Manifest spec, that wants a bunch of VCs and VPs, but things like proof of control/possession of DID is such a common pattern that it may be handled at another layer. Curious to hear how others are approaching. Which protocol we are doing it at.
  • Kristina: Interesting, aligns with discussions... Using SIOP for Authentication (like empty VP, proving... sending back an id token) vs using SIOP flow for VC/VP/attributes. In-device and cross-device SIOP. If relying party website is on same device as your OP (OpenID Provider): more secure to open session and do redirect, and share. Can do both authentication and attribute sharing. But also situations where RP is on another device, e.g. you are browsing at a terminal. Usually would show QR codes... opens up a phishing opportunity. Usually okay to do one-off exchange of VC/VP, but maybe not a good idea to open session and share this auth session. VP as VC vs. empty VP... trying to distinguish security properties.
  • Adrian: curious about verifiable presentation of attributes. If the verifiable credentials were issued to different DIDS, because they were pairwise-pseudonymous relationships, would it be possible to avoid the verifiable credential, or to use verifiable presentations by simply proving a relationship between the pairwise pseudonymous DIDs, and presenting the verifiable credentials themselves. Or is there something going on beyond that presentation sense that we are talking about. Am I describing a verifiable presentation or not? To the extent the verifiable presentation includes a challenge as the difference described earlier, then there is a difference between wallet generating hierarchical deterministic DIDs when authenticates with ... providers. Seems like two strategies for authentication (not talking about empty VP). Can someone speak to this confusion of mine?
  • Kristina: Identifier assigned to me by issuer should be in VP.
  • Adrian; If relationship with Issuer is always a same-domain DID, how I identity by default, then the role of the VP is to prove linkage between the VCs issued to the DID... or to control of the linked secret if using the sovereign model.
  • Kristina: If don't care about identifier correlation. ... Sign using same DID... becomes more complicated if you want to use a pairwise id. In VC model, up to wallet to rotate... to use different IDs for different parties. Would go into the VC(?)
  • David: In Ping identity, different: if issuing long-term credentials, e.g. 20 year University Degree credential, if issued to a particular DID, then any time I share that, it is basically correlatable. With the JSON-LD model, there isn't a way to selectively disclose the subject... it will change the canonicalization. Reason we've looked at JWPs: option to selectively disclose subject. More transient relationship, e.g. present proof of drinking age, party presenting it to cannot tell am same person, and pseudonymous identifiers - concepts everyone is familiar with. SO not interested in DIDs as subject of VPs. You may have a subject that's a DID, but we also want to support leading with those other two use cases. Tech like linked secrets... when present credential, not using DID but using linked secret: not a rotatable key. Long-winded way of saying we have more interest in distributed log equivalence pseudoym ... Trusted non-shadowable pseudonym with party. Cannot have multiple accounts - they know it's still me - but not universally linkable like an email address. Like the APple approach, can do pairwise DIDs, but then have relationship with issuer... Coordinating relationships, each time new relationsihp have to tget new DID.
  • Adrian: Very clear. Is there a reference to read more?
  • David: From the JWP perspective, we're trying to write a blog post. Don't have anything to point to. Probably need to actually write something and publish it, about basically decentralized identity without requiring decentralizedeintifier. Not that I don't think they are valuable, but in the case of a VP I'd like it to be more like a breaking-the-glass thing. like if lost access to linked secret, can use DID, losing privacy, but have that option. Or if use case really needs to use DIDs: service integration, or a public identity, not worried about ultra-private, representing as a company, building a public reputation, I may choose to share that DID. But any place I use that credential and didn't share it, they wouldn't know it's the same party. Can't point
  • Adrian: Let's bring back RWoT
  • David: Let's reboot RWot,
  • IdentityWoman: Let's not. It had severe issues with D&I and Code of Conduct violations
    • Adrian but a great source of papers
    • IdentityWoman: but if all the women and POC feel crappy, neet to work it so they feel included
    • Adrian: I just want David's paper. But you're right, I don't disagree.
  • David: am in #wg-Interop Group. Reach out to me, and to Kristina as liasion/diplomat to OpenID Foundation

Agenda - 7 July - EU time - Informal Roundtable on SSI and "eIDAS 2.0"

  • Recording
  • Martin Boender from Sphereon, Xavier from ValidatedID, Samuel from Gataca, and other guests TBD (hopefully at least one from the INATBA identity working group!)
  • Recommended readings:
    • https://eur-lex.europa.eu/eli/reco/2021/946/oj
    • https://mydata.org/2021/06/04/guest-post-the-secure-platform-concept-for-europe/
    • https://ec.europa.eu/health/sites/default/files/ehealth/docs/trust-framework_interoperability_certificates_en.pdf (see section 5.2 on forthcoming W3C VC guidance)
    • Xavi: EU Wallet
      • remote control of a HSM that does qual sigs?
    • Xavi: other changes afoot: openness to possible acceptance for EBSI and blockchain signatures? EBSI as "trust service"/root of trust
    • Xavi: These two things look like a trust framework from one POV
    • Adrian: Is the EU going to qualify/certify the wallet, or can subject self-compile and still be recognized?
      • Xavi: I think Brussels is assuming nation-states will ~"certify" wallets, or at least allow-list/approve/oversee them. There will be toolkits or pre-approved libraries, I think, at least in some countries
      • Adrian: How does this relate to FIDO and passwordless? Apple will likely jump to the head of the line and get their wallet certified even if they don't honor the relevant standards... are there standards required for interop or JUST security testing?
        • Xavi: I think FIDO would one authN mechanism allowed/approved, but the private key still needs to live somewhere, and that's what theyre going to regulate; Apple might well be capable of delivering a wallet (and could readily be a QSP) but I'm not sure they're really advantaged? disclaimer: I have no particular insight, they're just my opinions
    • Jan: If eIDAS 2 isn't going in an SSI direction, we should definitely show them the light-- they read whitepapers, we should write one! The connection might not be clear enough; EBSI only for govt purposes, not private sector; priv sector usecases NEED an explicit approval-in-advance to get funding;
    • Ralf (Blockchains/Slockit): German BMWi Schaufenster program is giving an interop target/
  • Pam: Point of order: what is the topic, exactly? Are we unanimous on the problem statement about how certificate-based eIDAS is opening up to new architectures? Is this about roots of trust or trust frameworks?
    • Pam: My reading of the documents makes it hard to see what the real problems are
    • Xavi: Remit of eIAS 1.0 was Defining eIDs in a way that allows crossborder interop (incl mandatory fields, format of address, etc); that didn't work well for various reasons:
      1. Only 14/27 actually produced a notified eID scheme (i.e. only 14 countries actually have a digital id recognized outside their borders),
      2. Protocol-level interactions were never really defined; a wallet controlling one of those eIDs doesn't have requirements or capabilities owed them by other systems
      3. Adoption stalled bigtime in many of those 14 countries- <5% of population in most of the 14 actually have and use these eIDs/eSigs
      4. crossborder recognition was public-sector only in original scope; private sector never NEEDED to have private-sector buy-in or support, and only now starting to move in that direction; VCs might be the target there
    • Xavi: EBSI might still be public-sector only, BUT if it supports the creation of wallets and VC constraints that then get reused widely by private sector... that might solve problem #4
  • Markus: Self-intro; EBSI diploma use-case, issuing educreds to EBSI eID holders; to answer Juan's original framing, the EU digital id & VC-holding wallets and EBSI should be seen as two distinct movements, even if EBSI is making a wallet that seems to be steering towards compatibility/eligibility for what EUID calls a wallet
    • Markus: Memberstates still can chose to adopt, or fork, or betray whatever EBSI does... could be interop nightmare, or EBSI could create a common toolkit even if countries fork. One lesson that came out of the eidas 1.0 "review period" feedback-- chaos of independent implementations across EU is what they want to avoid this time around, they seem to be
    • EBSI: European Blockchain Services Infrastructure
      • It is "a blockchain" (ECP) in the literal sense (each nation state gets 1 or more nodes of a permissioned ledger for public sector usage); it's using EC tech support to prove a few use-cases
      • Technical requirements for wallets: Sept21-Sept22, which will culminate in a toolkit of reference implementations AND specifications
  • Kai: Self-intro; stakeholder dialogue and EBSI proposal 2 years ago, altho project scope and focus keeps evolving
    • initial impetus - use blockchain to redo the parts of eidas1 that never got adoption/traction
    • pilots at nation-state level are currently launching-- the public sectors of these member-states (EU + 8 others: Norway, etc) are bringing agencies and/or private sector actors in to start piloting on this infra
    • Markus: Edu use-case in Austria is piloting with DanubeTech, 2 universities are trialing issuance of edcreds to EBSI eIDs; other pilots being added (10 or so: txns, edcred crossborder interop with Spain and Germany;)
  • Pam: Naïve interop question - interop at blockchain level? not at VC level? or have I got it wrong?
    • Markus: I think DID layer is easy because did:ebsi; semantics/LD/ontology layer is what the universities are focusing on;
    • Pam: Can people use libraries?
    • Markus: Universal Resolver and Universal Registrar support did:ebsi already, not top-secret
  • Adrian: Certified National Wallet & DID method? Data models for DID and VC are separable, so what's the relationship?
    • Xavi: My impression is that the two systems are distinct - I can see DID usage and VC usage as being a venn diagram, some will use one and not the other in different use-cases.
    • Adrian: DIDs as solution to key rotation problem? Stable IDs with rotatable keys? (Sam C: AND SERVICE DISCOVERY tyvm)
    • Pam: also [non-]repudiation, non? Privacy preservation (national IDs used anywhere without tracking) yet legally-binding signatures? What trust framework backs the legal side of things?
      • Xavi: ledger as QTS is being proposed as a trust framework that could be specified for legal signatures and notarizing
  • Oliver: eIDAS2 language around wallets
    • Kai: eIDAS2 and EU ID are still independent, but "eidas 2 toolbox" (started sept2021, released sept 2022) should specify the overlap of that Venn Diagram and INATBA is trying to inform both projects
  • Closing thoughts: what should people read to get involved? What's the library or toolbox to play with now?

Agenda - 30 June - US time - John Jordan - the ToIP vision and governance for decentralized identity

Agenda - 23 June - EU time - Updates on various work items: WACI-PEx, FAQ, etc

Agenda

  • WACI-PEx -
  • FAQ
    • This WG can and should extend these!
  • Identiverse -
    • Announcements -
      • Ping's Shocard product is live - W3C compliant?
      • Okta and Mattr partnered, Mattr VIII Platform integrated to Okta marketplace
      • ION AMA session (deep tech questions from the audience imply people are actually playing with it)
    • Strong Signals
      • Risk and Fraud analysis was a huge topic this time around - Synthetic identities, insurance, detection, mitigations
    • Weak Signals
    • Particular sessions to check out
      • Solarwinds with Alex
  • New WGs
    • Wallet Security WG -
      • Wallet assessment and assumptions - how to define which wallets are or are not secure enough for a given use case or type of information in a given jurisdiction
      • out of scope: UX, protocol design, signature suites, etc
      • Tuesday every week, already meeting, charter signable
    • Applied Crypto - BBS+ 2.0 as first work item (possibly also SNARK stuff from MSR) first meeting wed 7Aug, charter already signable

Agenda - 16 June - US time - Good Health Pass Blueprint by Drummond Reed, Global Covid Certificate Network by Lucy Yang.

Drummond presnted from this set of slides.

Minutes

Agenda - 9 Jun - EU time - Why do you need DIDs for SSI, with guest David Chadwick (Verifiable Credentials Ltd., UK)

Minutes

  • x509 as issuer ; "DID" for holder to express a key (did:key like encoding from IETF RFC)

  • Q and A

    • Adrian: Biometrics on slide 8? all identitIES need be issued by centralized parties or at least tursted 3rd parties?
      • David: Authenticating real-world person against account requires centralizing records, tho
      • Adrian: but VCs could be held without registration and presented by biometric authN?
    • Adrian: Biometrics can't be ignored- they disrupt some of the assumptions of this presi
    • Adrian: Protocols for VCs should not presume DIDs
      • VCHTTPAPI and Vp Request spec and similar protocols should not PRESUME DIDs
      • Adrian: DIDComm and CHAPI presume DIDs
      • David: I would prefer they presume public keys (even transient ones)

Agenda - 2 Jun - US time - BMWi Schaufenster, IDUnion, and new interop targets w/Hakan Yildiz

Agenda - 26 May - EU time - Open Discussion

  • Internal vs External interoperability (summary by Adrian)
    • Internal - examples are vendor lock-in for example
    • External - protocol decided by holder not issue (ie treat delegation as a human right)

Agenda - 19 May - US time - A quick tour of the WACI specification (recently donated to DIF) by Jace Hensley (Bloom) and a Q&A about the new WACI-PEx work item

  • Recording of whole session & of just the WACI presentation (on youtube)
  • Jace will give a tour of the WACI spec - what it does, what it specifies, what you can do with it
  • Q&A about the v0.1 and v1 scopes for the WACI-PEx work item/draft spec, with world-class cat-herder Brent Zundel as respondent

Agenda - 12 May - EU time - Aries-ToIP Interop with guests Lal and Jan from iGrant.io

Presentation

Agenda - 5 May - US time - IIW recap & Killer Whale Jello-Salad Update

  • Recording
  • first half: all members are welcome to share and recommend their favorite sessions (let's gather the links in this document!). Some strong signals:
    • KERI <> TrustFrame/ADL: two kinds of DID-like but non-DID identifiers and how they can work with DIDs
    • Credential Exchange across stacks ASAP - the Jello-Salad issues
    • Lots of Covid talk, and governance talk, and legal talk, including some detailed guardianship, delegation, audit, and regulated-finance use cases!
  • second half:
Minutes - IIW highlights? - all notes [here](https://iiw.idcommons.net/IIW_32_Session_Notes) - Adrian: 3 IIW panels: - Recommend people check the minutes/recording of AuthZ session - Polic Stuff - WACI - Have the group codify technical components of WACI individually, so we can generated momentum now. - PROPOSAL (from daniel B): marshal DIF, HL, ToIP, and/or CCG to jointly designate components of WACI as THE common ground for VC exchange
  • Interop Showing
    • DW: no implementations? PE has 1, BBS+ has 1...
      • PE is not minimal!

Agenda - 28 Apr EU Time - How Trust Frameworks Compare and Develop (OIX)

  • Recording
  • Nick Mothershaw (UK) from the Open Identity Exchange will talk about the guide to defining, enforcing, and comparing trust frameworks that OIX released last July
  • Pam Dingle (Microsoft US) will serve as respondent, drawing on her own experience mediating trust frameworks and working with OIX

Agenda - 20-22 Apr IIW - cancelled

Agenda - 14 Apr - EU time - FAQ crowd-editing sesh and IIW session ideas/matchmaking

  • For the first portion of the hour, we'll be walking through and giving the group a chance to hack away at a simple public-facing, entry-level FAQ for basic SSI topics
  • For the second, we'll gather thoughts about IIW panels and workshop scopes or invitees with the group. The best IIW sessions often have two or three conveners that don't work together or on the same tooling!
Minutes
  • IIW session spitballing
    • Juan + Sam: Rebase -
    • Adrian: GNAP AuthZ & SSI - Authorization-first versus Messaging-first (are we too data-model-centric/-forward?)
    • Sam: Medical Data and Credentials - what can a subject hold and what cannot? Data access vs protocol with concrete use-case examples (question-driven)
      • Adrian: Can we get Solid folks in there? Invite Dmitry Z?
      • Sam: Major overlaps with GNAP, EDVs, Hubs, and Solid equally!
      • Sam: Philosophical and legal limitations are not well known to many people working on these problems...
        • Adrian: Alice to Alice
        • Sam: US Law requires many things NOT to be self-held-- then we can map those to currently architectures and options
    • Adrian: Trustee + HIE of One semi-demo? (a self-sovereign agent for health records)
    • Neil Thompson (working iwth Paul at ToIP/HCF) - OCA session (also Health Data-friendly)
    • Stephen - DID:Indy method and resolving full did doc support in Indy - extract all ledger data in more w3c ways
    • Stephen - organizational wallets - legal registered entities
      • Moritz K (Bosch) - Org Agent - Indy + web frontend for spitting out did:web VCs
    • Kristina
      • OIDF/SIOP group --> using VCs with OIDC: 3 options;
        1. JWT claims to embed entire VC inside the ID Token;
        2. Having a dictionary - Aggregated and Distributed Claims syntax;
        3. a new artifact that includes only VP (aka VP token)
      • BBS+ with JOSE (Ping)
      • Credential Provider spec (Tobias and Adam L: issuance spec)
      • wallet invocation (SIOP chooser) - how to invoke one wallet of many
        • Adrian: Password managers and wallets?
        • Kristina: CHAPI-inspired & share-page --> how to servers ask for a wallet and get one back it can work with
        • WebAuthn has some hints
      • SIOP use-cases - what do you want to use an Identity Provider you control for?

Agenda - 7 Apr - US time - VC-Status-List-2021

  • Manu Sporny of Digital Bazaar (US) will be discussing the new VC Status List spec at CCG and how it could relate to VC Refresh and other next-generation flows.

Agenda - 31 Mar 2021 - Trust Framework Talk

Minutes:
  • Sankarshan: Update on UK Trust Framework
    • it's "ALPHA", still collecting input for BETA to be released before made policy
  • Sam Curren
    • Intro to concept (tour of RFC 430)
    • First QandA
      • Adrian: How's this relate to a platform app store, which is a machine-readable trust framework of sorts? App stores' opaque and arbitrary policies raise real problems for separation of concerns; does MRTF make possible a more transparent or openly-governed policies? I think so!
        • Scope is for VCs, though, not software
      • clear, simple example in this PR

Agenda - 24 Mar 2021 - US/APAC time (1400PT) - SVIP Plugathon Report-out & Aries Interop Update

Minutes:
  • Aries (Rapid-fire tour by Stephen!)
  • Q and A
    • Andreas: Kudos on including attack vectors in Mallory! What's she get up to?
    • Andreas: All the AcaPy and harness all in Kubernetes; AcaPy now multi-tenant
  • Anil: SVIP
    • VC-HTTP-API should catch up to this presentation and user-friendliness!
    • BBS+ update
      • David: Predicate proofs? Stephen: not in the AIP2 community
      • Sidenote: Evernym blog post about predicates and BBS+
    • DID:Web for issuers
    • Foundational piece on JSON-LD
  • Q and A
    • Anil: Scoping plugathon to narrower profile?
      • Rouven: Cross-Industry plug-a-thon? Smaller than profiles, just one or two tiny things, like everyone can present a VC over DIDComm?
      • Keith: Crypto opinions & NIST/FIST/Fed? Ed25519? what else?
        • Anil: To blockchain or not to ledger is actually a red herring; public blockchains are kind of unlikely to get acceptible any time soon; FIPS-compliance is
        • Anil: NIST has a great whitepaper on pairing-friendly curves; I pinged two of its authors specifically about BLS and BBS+, and we had to ask them to look into it;

Agenda - 17 Mar 2021 - US/EU time (0600PT) - DIF ["Mini-"] Grant Program

Agenda - 10 Mar 2021 - US/APAC time (1400PT) - Justin Richter and Adrian Gropper on GNAP and Authorization for SSI

  • Announcements

  • Advanced Readings:

  • Justin will give a quick presentation on recent developments in GNAP world, and applicability to AuthZ requirements of SSI-based systems

  • Adrian will serve as respondent and structure a conversation with some notes

    • time allowing, Adrian might also give an update specifically on GNAP and AuthZ discussions in the Confidential Storage working group, which is currently refining use-cases and re-scoping for v1
Minutes & Diagrams: Presentation - Next steps for GNAP group at IETF

  • GNAP and SSI

  • Naïve vision of everyone being their own AS:

  • But GNAP envisions AS more as a token factory:

  • Fancier version: User isn't only human that can intervene/chip in (RO = Resource Owner)

  • Q n A
    • Adrian: Isn't factory model leaking policy info to requestors?
      • Justin: No, token has very little baked into it
      • UMA versus UMA2 - limited-trust environments prefigured today's zero-trust, user brings some data with them
    • Audit
      • ongoing request and nonrepudiability - "txn"
  • How to get involved - no CLA or joining process, just jump in!

Agenda - 3 Mar 2021 - US/EU time (0600PT) - Manu Sporny (Digital Bazaar) report-out on specifications incubated in W3C-CCG

Details:
  • Manu self-intro
    • retail finance and govt
  • Roadmap of CCG specs
    • Overlap of communities
    • First question break
      • Oliver- PresExch vis-a-vis VP Request spec?
        • Manu: Lots of VPReq work is driven by US and EU govt requests
        • SVIP not identifying VPReq spec as an interop target
          • demonstrable interop and working e2e systems are two directives to be balanced in the SVIP program
          • lots of "fast tech" decisions made to favor these directives in short-term
        • Manu: PresEx is more complex and full-featured, whereas VPReq is more MVP-like; i'd love for them to converge over time but I don't see a lot of
        • Oliver: interop profiles/spec subset approach?
        • Charles Lehner (in chat): converge is possible if we start now...
          • Manu: VPReq spec comes out of CHAPI
        • Manu: Subset profile could be a good approach to get partial alignment along the way
      • Kristina: Where's VC 1.1 work happening? where's the draft spec?
        • Manu: VC WG Maintenance group is working here (on main branch) - "canary in the coal mine" of W3C maintenance processes - Wayne Chang (Spruce) and Brent Zundel (Evernym) chairs, Ivan Herman = contact
        • v1.1 = no new features, just bug fixes, errata, and documentation upgrades
        • v2 = Mattr chomping at the bit to add some display features :D
        • Breaking changes planned? Manu: NEVER! Deprecate features at most
      • James: Tipping point for adoption and uptake? Manu: we're certainly closer to it than a decade ago, when W3C was bombarded with decentralization opposition
        • Manu: Fundamentally, we have to prove (and specify/make testable) how it's a better mousetrap, and we're all working on that
      • Rouven: Linked-Secret in scope for any of these specs?
        • Manu: At least in US govt-based work, there's been little interest in it, but BBS+ (which relies on pairing-friendly curves) is picking up steam (IETF-CFRG is now doing formal review into the underlying math BN and BLS-- govts won't touch anything without that kind of crypto analysis, and luckily many of them defer to IETF-CFRG)
          • Manu: I think the linked-secret math in its Sovrin/Indy form relied was a blocker for Indy adoption
          • Rouven: But can't BBS+ issue to a linked-secret instead of a DID? I was asking more about issuance to non-persistent identifiers...
          • Manu: Oh, fair, that's a separate question; there is interest in binding to non-permanent identifiers for the sake of ZKP and selective-disclosure; CFRG is interested and EU and US govt agencies as well
    • Back to tour of chart
      • green = general data formats
      • blue = data model
      • yellow = vocab
      • magenta = protocols
      • purple = crypto
      • orange (at the end) = app-level specifications (agent-layer?)
    • Juan: How can DIF companies help? Urgencies caused by big-company resistance to "all this" (LD-centric plumbing?)
      • RDF Dataset Normalization
      • LDProofs
      • Cryptosuites (partic for Edwards and JOSE interop)
      • This is fairly specialized stuff, but providing review and implementations is huge, we needed it all years ago
    • Adrian: More detail on protocols plz? Manu: Wire/transport Protocols are the protocols we mostly work on- CHAP, VC-HTTP-API, and VP Request Spec -- there hasn't really been convergence, we all want it but no real plan yet
      • CHAPI can move VCs but also ZCaps, DIDComm, OIDC... you can run subprotocols over it
        • Browsers don't just use HTTP-- there's all kind of service workers and cross-tab posts and push and put and... CHAPI lives in that sub-HTTP world
        • Oliver: CHAPI + Native apps? Manu: But native apps mostly use DIDComm, so they don't need it so much. A few native apps have made that work, but it's not widespread enough to standardize - a company hasn't stepped forward to put weight behind that initiative
        • Oliver: But is that in scope of CHAPI work? What would the API look like for a native app, and could the CCG spec specify it? Manu: It could work the way websites invoke native apps (google map link in browser leads to scheme/protocol handler, or via mime-type... callback URL); CHAPI is a failure if we can't do that
        • Adrian: Password managers, for example; Manu: But that gets into standardization and browser-plugin to avoid proprietary stuff; choice of wallets hard to protect from browser standard bias...
        • Adrian: Consent and credential handlers: healthcare use cases tend to need consent and KMS concern separation; how does that work in this vision of CHAPI?
          • 4-8 years of data gathering before browser-API standards can surface concerns and priorities; for now, it has to be wild wild west (and outside of browser control).
      • VP Req is basically a Vocab, not a protocol...
  • Please for help/participation
    • 8 chartered WGs - 6 of these need to end in a global standard for this to work :D
      • we need specs, test suites, sample implementations...

Agenda - 24 Feb 2021 - US/APAC time (1400PT) - Revocation Mechanisms Pt. 2 - Mike Lodder and Revocable BBS+

  • Intros and announcements
    • Wallet Security WG kickoff Monday
    • Mike is also working on a bearer-token/passwordless auth system as well?! coming soon to an interop near you...
  • Mike will be talking about his proposal for "Revocable BBS+", an early-stage specification that may some day be a registered W3C status mechanism!
Minutes

Non-Private Methods

  • lists
  • merkle trees (just more efficient lists)
  • service check (i.e. status server)

Pseudonymous Methods

  • privaty info retrieval (PIR)
    • download entire list, check for value
  • forward revocation list
    • non-revocation proof, check every itemn for match - more computationally intense, but less leaky

Anonymous Methods

  • Crypto circuits: SNARKS, STARKs, SNARGs, Bulletproofs
  • Accumulators:
    • RSA
    • Hyperelliptic
    • Pair-based
    • Range-based

Indy Style

  • Tightly coupled to CL :(
  • tails file
  • size can't be helped

Merkle trees w/circuit proofs

  • various options
  • only in production in one place: ZCash (they still have problems with it)
  • more and more circuits, complex details about trusted/semitrusted setup...
    • "you need a PhD in math to even research the options"
  • easier to understand storage - can be 1bit for boolean
  • v complicated - huge
    • 10 seconds to download, 3 seconds to compute, 3 seconds to verify...

Hyperelliptic curves - only 2~3 years old

  • no trusted setup - i.e., no one has to hold a private key
  • security not yet hardened
  • easier to verify
  • 2k accumulator
  • Eth Foundation was looking at this for huge merkle trees w/o trusted setup -went in another direction since?

RSA

  • trusted or trustless setup (req. MPC)
  • accumulators have a fixed size, regardless of size of set
    • add trustless, but delete needs a private key (unless it's computationally super expensive) - 60-70ms each

Bilinear Maps Accumulators

  • CKS
  • Nguyen
  • ATSM
    • deltas could be applied with a XOR - easy peasy
  • Thakur
  • Vitto-Birukov * my fav
    • tiny proofs (under 300bytes)
    • have to publish deltas if you make any changes (local witness needs process all these)
  • pairing-based (not secp or ed25519; requires pairing curves)
  • BBS+ cred exchange + any of these --> "revocation for free"
    • HOLDER has to fetch and apply deltas -

Questions

  • Martin: BBS+ revocation versus BBS+ in general
    • does bundling revocation AND ZKP confused the issue? does BBS+ measure up well as a revocation mechanism and as a ZKP mechanism separately?
  • Adrian: Single-use credential?
    • Mike: Don't use any of this stuff! Privacy-Pass - Single-use ZK token :D

Revocation is just difficult mathematically to scale

  • accumulators seems to win, every time, by 100X or more, against SNARKs, SNARGs, etc
    • SNARKS, SNARGs, etc are great for ZKP... just not really great for this problem
  • bilinear map scales the best
    • leak less privacy than lists

Agenda - 17 Feb 2021 - US/EU time (0600 PT) - Updates on Layer 1 recent events

  • Recording and Slides

  • Reading and links:

    • Step-by-step guide to registering a DID Method presented on I&D WG 8 Feb - see item #6 and recording

  • Updates from recently-registered DID methods:

    • DID:Orb
      • Special guest: Troy Ronda (SecureKey) will be discussing some of the peculiarities of DID:Orb, including its use of the ActivityPub gossip protocol for propagation of records and its usage of self-certifying identifiers
    • DID:Tezos & DID:Doge
      • Special guests: Wayne Chang and Simon Bihel (Spruce)
  • Announcements
    • Wallet Security WG refining its charter and looking for a co-chair to begin work soon! Get in touch via DIF Slack
Minutes * Intros - Andrea from Dyne.org - [DECODE project](https://decodeproject.eu/) moving towards W3C compliance soon - Hakan - reintro - good to be back, ping me on Slack if you have any questions about the IDUnion Indy network now supported by the BWMi here in Germany!

!!!

  • Troy - ORB Walkthrough
    • Intro to Sidetree in general
      • loose ordering/no ordering needed
      • each controller manages directly a portable, offchain hashchain for each identifier
    • Orb specific
      • "allow ledger usage as a monitorable log"
      • open federation based on loyal/total replication, not subset or second-order data model
      • minimize trust
      • web-based discover
      • "assigned timestamp + promised write" = "cert trans concepts" ("late publishing" in sidetree spec)
      • "observer" & "anchors" = Sidetree concepts
        • Anchor role encoded in a VC
        • "VCT" = VC transparency (//cert trans)
    • question-break
      • Martin: What's a ledger-node need to do to be a witness?
      • Adrian: Where are signing events in this? Can those also be logged (yes but at layer 2, not layer 1)
    • more details
    • github - reference implementation being built in Go on Fabric (variant of trustbloc)
    • More questions
      • Martin: how dynamic are the witnesses? can you change witnesses in the lifecycle of a did?
        • Troy: DID Controller picks an "origin" and that includes one or more witnesses, which are updated in the lifecycle/sidechain of each controller; new version writes that explicitly into the docs; canonical CIDs have to be rotated at each origin-move or recovery event (basically, old identifier still works but metadata includes a "redirect" to tell you about the change of canonical)
        • extra witnesses co-sign lots of things
      • Martin: conflict resolution built into late publishing, right? witnesses changed during the window of publishing?
        • open federation risks witnesses disappearing; "non-canonical DIDs are treated as minimal graph point"
        • synonymous identifiers point to the same "original did";
      • Rouven: Will this be a work item in DIF some day? Troy: We want it into an appropriate working group, CCG or DIF
        • overlay - anchor credential format and overlays = not specified

Agenda - 10 Feb 2021 - US/APAC time (1400PT) - Revocation method comparison

Context and Recommended Advanced Readings:

Agenda - 3 Feb 2021 - US/EU time (0600 PT) - Update on DID-Core and Enterprise Ethereum Alliance (D Burnett) and DID Interop Fundamentals (Markus Sabadello and guests)

Announcements

  • Wallet Security WG - come to biweekly later today!

Context & Recommended Advance Readings:

Minutes
  • DID-Core update from Daniel Burnett
    • self-bio - illustrious standards career (never knew the WebRTC piece!)
      • important update: Brent Zundel and Wayne Chang taking over VC maintenance group!
      • Consensys and Enterprise Ethereum Alliance!
    • 2 year charter period = standard for a recommendation-track spec
      • all other outputs are non-normative and non-rec track (usecases + reqs, implementation guide, rubric that came out of RWOT)
      • DID Resolutions spec is NOT a work item of the W3C DID-Core group - that's CCG!
        • industrial participants in the group lobbied against scope creep- resolution put out
        • not just resolution but ALL operations put out of scope of the DID spec itself (just the identifier, ma'am)
        • DID-Resolution interface defined in did-core, but only that
      • W3C not a fan of extensions - implementation reports (provided by implementers about the group's test suite), which are due one month after getting to "proposed recommendation" freeze
        • Feb 9 - any issue without a PR gets put on ice for now
    • Problem Issues :D
      • Informational appendices (some might be W3C notes)
      • DAG-CBOR editorial snafu and maturity issues (W3C Note might make more sense than an appendix?)
      • Let's not forget the extensions registry! It explicitly permits new representations (incl additional/future CBOR variants)
      • W3C - Objection process
      • Implementation reports - Orie is taking lead on this one
        • Open to non-members
  • EEA - making Ethereum safer and easier for businesses to use
    • Public mainnet and consortium uses both in scope
    • Enterprise Ethereum (competitors to Fabric and Corda, exc with a mainnet)
      • {more devs than anybody, hehe}
      • Specs for enterprise
    • EthTrust working group - levels of security audits for smart contracts (auditing badges)
      • actual audits outsourced to security auditing firms
    • New DeFi interest group - should be popular
    • Eth2 interest group coming soon
    • Portable ID check/eKYC for cryptocurrency onboarding - need to be more portable than conventional banks!
  • MultiProof VCs - Presi
    • LD Proofs spec (independent spec) - includes possibility of multiple proofs!
      • Proof Sets (serial) versus Proof Chains (cumulative-- includes previous signatures)
      • Troy: Our Orb method does this!
      • examples in the wild: Essif v1 VerifiableID (secp with did:ebsi-eth:xxx#key-1 + eidasSeal2019 with cert)
        • Xavier: we're (Essif) are updating this now: AES is our assertionmethod: XADES, PADES, or now JAdES based on JWS (CR in ETSI)
        • Markus: one thing we discussed back then in the v1 days was just signing the VC with the DID but put the Eidas Seal in the DID Doc;
    • verificationMethod type EidasCertificate2019 was just a proposal; JAdES vM will however be registered with W3C
    • example #2 from USCIS PRC project
      • non-signature proofs! proof of work, hash of credential being registered on a blockchain (forgotten trend-- adds little security and adds correlation :D )
    • example #3
    • example #4 - Veres One uses some amount of POW when you register a DID... that might be another example of non-sig assertion method
    • Troy in chat: The Orb setup is very much like certificate transparency … since we use VCs instead of X509s, we call it Verifiable Credential Transparency :). https://trustbloc.github.io/did-method-orb/#vct-v1
## Agenda - 27 Jan 2021 - US/APAC time (1400PT) - ~~Todd Gehrke (ID2020) + Josh Mandell(Microsoft Healthcards Project) ~~

Context:

Impromptu agenda

  • Adrian: separation of concerns where IETF does protocols and W3C does data models
    • authorization and messaging as yin and yang?
    • diversion through didcomm
  • FHIR brownfield entrenching EHR platforms/concerns?

Agenda - 20 Jan 2021 - US/EU time (0600 PT) - Tour of the OS Veramo Suite from Consensys Mesh/DAF team

Recording

Agenda

  • introductions and announcements
    • INATBA Roundtable happening tomorrow - come support DIF members Jolocom (Kai) and Transmute (Karyl) that are speaking on a panel with friends of the podcast Daniel du Seuil and Anil John!
  • Presentation of Veramo
Minutes
  • Intro - uPort history and relationship between Consensys, uPort, and Veramo
    • Veramo URL: http://veramo.io
    • backward compatibility with uPort, but more easily extensible and modular architecture
    • moving to a more messaging- and event-based structure
  • Architecture tour - highlevel
    • SDR - temporary presentation request while we wait for a wider standard to harden (will replace later with Pres Manifest or such)
    • W3C Credential (JWT)

  • Architecture tour - Plugins and modules
    • Agent Apps: Veramo CLI & Veramo Agent App (HTTP)
    • modular plugins that expose methods to each other via TypeScript API calls or via openAPI proper

  • Roadmap
    • LD Proofs coming soon
    • Presentation Exchange / Cred Manifest
    • Aries & DIDComm v2 (will replace native Veramo messaging)
    • DID:Ion ?
    • Modular enough that other people can write plugins for any ZKP presentations and verifications people want, be our guest!

  • Juan's questions

    • Data store (SQL?) versus EDV? Key manager versus KeyCloak or WebKMS?
    • REPLACE messaging with DIDComm? Backwards compat?

  • Q and A

    • Adrian: This is great, feels like it
    • Adrian: Is this an attempt to remake GNAP AS for SSI tools? Or is the future API fortresses?
      • Future agenda item?
      • Oliver: I think the veramo plugin system with remote plugins would work with GNAP, depending how you divide labor between parties in your architecture; I can definitely imagine a plugin method using GNAP to convey privileges between remote plugins on diff exec environments; we see that as in scope;
      • Oliver: I'd be really interested to hear you speak about what GNAP's role would be? It's important, sure, but it's also specific to the architecture you're imagining
      • Sam Curren: This architecture can use its backend service an agent, but that agent isn't an AS, although it can work with one; client/server model is a weird fit to agent-to-agent architectures, so not incompatible;
      • Sam: Pluggable authZ schemes depend on what role it plays (as agent)
    • KMS versus other KMSs
      • Key Manager is not to replace, just an interface (webKMS could replace it, if someone made an interface for it; EDVs could replace the data store if someone figures out the custom API)
      • Rouven - could also be used as a testing framework with DID:Key - all you need is a few plugins
    • Pam: This presentation was very complete and professional-- OS, right? How would you sell this to a customer? How do you sell this? I would like to amplify this.
      • Rouven - enterprise plugins & legacy support plugins for hire :), not much
    • Sam: Pushing messaging problems into resource framework?

Agenda - 19 Jan 2021 - DIF Face-to-Face - (800-830PT) - Report out of Interop since last F2F

Recording

Agenda

  • What our deal is (5min tops)
    • Relationship to other groups
  • Review Projects done (10min)
    • Invite people to speak up who were part of them
  • Proposed Work Items? (5min)
  • Past topics (5min)
  • Future topics (5min)

Agenda - 13 Jan 2021 - US/APAC time (1400PT) - Communications Problem: Explaining the VC Format wars to decision-makers

Recording

  • Optional homework: skim, read, or best of all, leave comments on the draft of Kaliya's LFPH/CCI public-facing lightpaper on the subject
  • Walkthrough of paper (10min)
  • Review
  • Warmup discussion: How do you describe the VC format decision to decision-makers, clients, outsiders, etc? (10min)
  • Crowd-edit and pile-on (30min)
  • Closing discussion: where does this paper go and what else can be done to make this clearer (or obsolete)
    • Sidebar: Covid credentials
Minutes * Walkthrough of paper (10min) * Scene by Scene * Scenes that need the most love: 8, 9, 10 * Review * Marty Reed: Partic in ed, we talk a lot about human-readable, * Keith: I've had lots of these conversations with decision-makers, but... how do we cut through the complexity to them? * Keith: Can we phrase it as betting advice? Are you telling people to bet on one horse? The paper seems a little biased in favor of BBS+ IMHO... * Kaliya: We can't pretend these differences don't exist * Keith: I felt this paper glossed over the pairwise DID * Sidebar on which systems use pairwise (including JWT, ZKP-CL, and LD systems!) and others don't (in all the same categories)-- it's a cross-cutting (transversal?) category * Scene 9 BBS+ walkthru (Kyle dH)- issuer signs VC (which has a **signature** on it) and holder signs VP (which has a **proof** on it). * Scene 10 - * Kyle: what's diff between ZKP and nonZKP - all nonZKPs have in common not wanting to reveal the DID or the signature-- ZKP lets you withhold both holderDID and holderDID-Signature in VPs * Warmup discussion: How do you describe the VC format decision to decision-makers, clients, outsiders, etc? (10min)

  • Crowd-edit and pile-on (30min)

  • Closing discussion: where does this paper go and what else can be done to make this clearer (or obsolete)

    • Sidebar: Covid credentials

Agenda - 6 Jan 2021 - US/EU time (0600 PT) - 2020 Year in Review & Periodic Roadmapping Re-up session

Recording

Agenda/Minutes

  • Introductions
    • Adrian Field - PSD2/open banking and SSI interop
  • Year in Review
    • Report-out
    • Goals & Roadmap
  • Topic Parking Lot Review (See above)
    • Meta-topics/Multi-meeting Topics list added
  • Adrian: Human-Centric Protocols and Zero-Trust Architecture
    • Role definitions borrowed from GNAP pre-spec documents
    • Slides & Context from the CCG mailing list
    • Proposal to the group: 5 roles from GNAP thinking might be useful? Slippage between assumptions baked into terms used to define roles
      • GNAP - breaking changes from OAuth2/OIDC, roles have very different assumptions