<DAY> March <#>
Attendees
- Co-Leads: Darrell O'Donnell
- ID2020 PM: Todd Gehrke
Participants:
- Stephan Baur (Kaiser Permanente),
- Steve Megennis
- Drummond Reed
- Scott Perry
- Kaliya Young
- Sergio Ceron
Agenda Items
- Antitrust statement
- Document Review
Presentations
- Initial Presentation (Google Slides)
Key Resources:
- GHPC Blueprint Outline v2 - The Trust Registries section is detailed on pages 25-26.
- WHO SVC Guidance
Recording - Link
Notes
1. Welcome and Linux Foundation antitrust policy - http://www.linuxfoundation.org/antitrust-policy
[Steve] We need to include a time consideration. It is too simple to just remove an issuer, we need to consider if the issuer was a trusted authority at the time.
Discussion about should the TR have the serve up the public keys.
General consensus is that the TR should be purely a place to determine if the issuer is authorized, for offline the verifier will need to resolve all keys for their original source.
[Drummond] We can say it’s not our job but it leaves an unsolved problem
[Steve] This is a problem for the verifiers have a well known URL to resolve the keys
[Drummond] A did:web: DID can redirect to a did:key: DID for the X.509 certificate.
to give us a short description of how using DID:wen and DID:key solves the x509 problem
[Steve] Verify the Verifier discussion.
[Stephan] How does the holder know how to connect to the TR? The verifier is part of the GF and linked to the TR. Now we are saying the wallet is also part of the GF and knows the TR it will be using. This creates a bit of a closed loop system
[Steve] As we have defined the ripple as . . if we are going to use the same mechanism for Verify the Verifier then we need a fourth field to accommodate Verify the Verifier.
[Darrell] We need to finish this for today. We can follow up with more
To get updates in about Verify the Verifier
Resolve issuer
Resolve verifier
Action Items
- Darrell and Drummond to get updates in by noon pacific time.
- Todd to push the document to the review folder