W3C home > Mailing lists > Public > public-credentials@w3.org > January 2023

[MINUTES] W3C CCG Credentials CG Call - 2023-01-17

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Wed, 18 Jan 2023 11:15:22 +0000
Message-ID: <E1pI6PX-00BbXC-2q@mimas.w3.org>
Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:

https://w3c-ccg.github.io/meetings/2023-01-17/

Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:

https://w3c-ccg.github.io/meetings/2023-01-17/audio.ogg

----------------------------------------------------------------
W3C CCG Weekly Teleconference Transcript for 2023-01-17

Agenda:
  https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Jan&period_year=2023&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date
Topics:
  1. Announcements and Reminders
  2. Work Items
  3. Status of DID Resolution
Organizer:
  Mike Prorock, Kimberly Linson, Harrison Tang
Scribe:
  Our Robot Overlords
Present:
  Harrison Tang, Paul Dietrich GS1, Sandy Aggarwal, Jeff O - 
  HumanOS, Markus Sabadello, Andres, Manu Sporny, John Kuo, 
  Kimberly Linson, Erica Connell, Kaliya Young, Ross Power, Dmitri 
  Zagidulin, Ryan Grant, Lucy Yang, Jon St. John, Stuart Freeman, 
  Gregory Natran, Will, Joe Andrieu, Keith Kowal, Phil L (P1), 
  Kayode Ezike, Leo, Marty Reed, Kerri Lemoie, David Chadwick, 
  Andrew Whitehead, Nate Otto, TallTed // Ted Thibodeau (he/him) 
  (OpenLinkSw.com), BrentZ, Brian Richter, John Henderson, TallTed 
  // Ted Thibodeau Jr (via iPhone)

Our Robot Overlords are scribing.
Harrison_Tang: Alright hello everyone I hope everyone had a good 
  long weekend for those of us who are in the u.s. so we'll start 
  today's this week's ccg meeting.
Harrison_Tang: Before we start I was just going to the code of 
  ethics and professional professional conduct reminder the details 
  are included in the agenda that was sent out last week more or 
  less just be respectful to each other anyone can participate in 
  these calls however all substantive contributions to the ccg work 
  items must be members of the ccg with full IPR agreement signed 
  and you can join the ccg community.
Harrison_Tang:  from the links in the agenda that we send out or 
  email any of.
Harrison_Tang: The co-chairs my email is Harrison@spokeo.com 
  S-P-O-K-E-O.com.
Harrison_Tang: Alright so all the meetings are being recorded and 
  there's transcriptions that will be sent out this week we got the 
  transcription process working now so you'll be sent out about a 
  day or two days after the meeting.
Harrison_Tang: You can use the Jitsi chat to queue the speaker's 
  during the call you can type in Q+ to add yourself to the queue 
  or q- to remove yourself from the queue you can do a que question 
  to see what who's in the queue.
Harrison_Tang: Alright let’s go into the introductions and 
  reintroductions anyone want to introduce yourself or maybe you 
  haven't been active in the community and want to reintroduce 
  yourself. Please just come out of unmute
<kaliya_identitywoman> annoucements?
Harrison_Tang: All right I'll queue the introductions and 
  reintroductions at the end of meeting again for those who are a 
  little bit shy or don't know what to say at this moment all right 
  so for this week our agenda is we're pleased to invite Markus 
  from the new tech to present the state of did resolution as you 
  know at the meeting today Marcus.
Harrison_Tang:  obviously most of us know.
Harrison_Tang: Has been an active contributor to the ccg 
  community and we're very very pleased to have him speak but 
  before then thank you kaliya for reminding me I forgot about the 
  announcements so any announcements or reminders.

Topic: Announcements and Reminders

Kaliya Young:  Sure thanks so I just wanted to share again we've 
  got the I’m working with New Logic in Thailand to produce the 
  APAC digital identity unconference we just changed the venue but 
  it's still happening and I think it's going to be really 
  fantastic lots of interest from people around the region so if 
  you have staff in the region or know.
Kaliya Young:   Folks working in the region that could.
Kaliya Young:  Connect up with the broader community that would 
  be great to share it with them I'll put the link in the chat and 
  also in mid-march I'm producing the thoughtful Biometrics 
  Workshop to support uncommon conversations about this slightly 
  controversial technology and would invite identity people who are 
  interested in engaging in that conversation to join so I'll post 
  both those links and of course as usual.
Kaliya Young:   IIW has registration open.
Kaliya Young:  Now April 18 to 20th in the Computer History 
  Museum in Mountain View thank you.
Harrison_Tang: Thank you Kaliya.
Harrison_Tang: Any other announcements or reminders.
Kaliya Young: https://www.apacdigitalid.org/
Kaliya Young: https://www.thoughtfulbiometrics.org/

Topic: Work Items

Harrison_Tang: All right before we get to the main agenda and 
  there's also some requests on the questions on the work items the 
  first work item is the evidence property I don't see David is on 
  today so maybe we can talk about that next week.
Harrison_Tang: Manu any questions on the work items.
Kaliya Young: https://internetidentityworkshop.com/
Harrison_Tang: Okay cool and then the second one is there's also 
  a question last time about two weeks a couple weeks ago about the 
  did link resources specification so if there's questions please 
  just add the comments on GitHub or we can reopen that item 
  because I don't see Alex on as well.

Topic: Status of DID Resolution

Harrison_Tang: But we actually in our ccg calendar we have the 
  DID link resources specification topic scheduled for February 
  21st so so we can also talk about that all right so let's get to 
  the main agenda so as I mentioned earlier we're very very honored 
  to have the Markus here to talk about the state of the DID 
  resolution Markus has been very active and he's.
Harrison_Tang:  kind enough to.
Harrison_Tang: Contribute the DID resolution test Suite to the 
  ccg last September so without further Ado Markus you have the 
  floor.
Markus Sabadello:  Can you hear me yes alright then I will try to 
  show my screen.
Markus Sabadello:  Is that working.
Markus Sabadello:  It's okay fantastic so yeah thanks Harrison 
  thanks for the for the invitation I'm Markus I'm one of the 
  co-editors of the did core specification and the did resolution 
  specification which I can talk about a little bit now how long 
  should this Harrison how much how much time should I.
Harrison_Tang: You can take as much time as you can you want 
  yeah.
Markus Sabadello:  Okay so I try to have prepared this in a way 
  where I'm not not starting from scratch right so not not going to 
  explain all the foundations of dids and did documents I assume 
  everybody knows most of that everybody probably knows that did 
  resolution is the process of taking a did and getting the did 
  document associated with the dids so I’m not going to explain all 
  of this in.
Markus Sabadello:   Detail but I thought I'm going to start with 
  just
Markus Sabadello:  Some some motivation to remind ourselves how 
  how important and how fundamental did solution really is because 
  it happens essentially all the time right if we do anything with 
  verifiabler credentials or chapi or didcomm or open id connect 
  it's always did resolution there's always a need to discover the 
  did document to discover metadata about the subject that's 
  identified.
Markus Sabadello:   By the dids so here are some common examples 
  that.
Markus Sabadello:  Probably everyone here is familiar with but 
  just as some inspiration in them in a verifiable credential if we 
  want to verify the proof of a verifiable credential we need to 
  resolve the issue did to look up the issue as public key if we 
  perform some kind of did auth flow did auth interaction whether 
  it's based on chapi or didcomm or open id connect there is always 
  some kind of challenge response pattern and.
Markus Sabadello:   There's some kind of signature signed by 
  someone who's identified by a did.
Markus Sabadello:  So I can we need to resolve the did and of 
  course we also need to resolve dids for discovering somebody's 
  didcomm end point or decentralized web node or some other kind of 
  service it's a really very fundamental function and because of 
  that there are also a lot of implementations out there right this 
  is just a very small subset of implementations that somehow 
  implement the did resolution.
Markus Sabadello:   Process there's the dif.
Markus Sabadello:  Universal resolver which is a resolver that 
  can be run as a service and then there are several libraries 
  veramo did kit Hyperledger Aries typescript resolve so there are 
  resolvers implementations of did resolution they come in 
  different forms and different languages and sometimes they are 
  Standalone components and sometimes did resolution is built into 
  something else so there's a lot of.
Markus Sabadello:   Variety and quite a lot of implenmentations.
Markus Sabadello:  Because dids and did resolution are so 
  fundamental to other things how is this defined right now so how 
  do we know how did resolution works and the answer is there's a 
  little bit of content in the did core specification which as we 
  know as a w3c recommendation it has an entire section about 
  resolution.
Markus Sabadello:   And it also has a.
Markus Sabadello:  Section about the the identifier of course 
  which talks a little bit about did parameters so these are some 
  things that we have in the did core specification that have to do 
  with with did resolution there's a definition of some functions 
  resolve function resource representation the referencing 
  functions and these functions specify what is the input and what 
  is the output.
Markus Sabadello:   So for example.
Markus Sabadello:  If we resolve a did then there's really the 
  did as one input and resolution options as another input and then 
  as an output we get the did document but then we also get two 
  types of metadata did resolution metadata did document metadata 
  and some of that is also defined in in did core already so this 
  is already a standard it defines some resolution option called 
  accept.
Markus Sabadello:   It defines some.
Markus Sabadello:  Resolution metadata called content type and 
  error and some did document metadata about the did document when 
  was it created when was it updated and and so on and then as I 
  said there is also some did parameters did parameters are part of 
  a did URL if we have a not just the did but a did URL with a path 
  and the query string and and fragment.
Markus Sabadello:   And did core also defines.
Markus Sabadello:  Defines the syntax of that and then defines 
  some of these did paramters.
Markus Sabadello:   Now what.
Markus Sabadello:  Did core did core standards doesn't Define it 
  doesn't actually Define how this is really implemented in did 
  core these things are related to did resolution or defined in an 
  abstract way they are abstract interfaces with some abstract data 
  structures but the did core specification doesn't Define for 
  example a concrete algorithm if we look at this example.
Markus Sabadello:   Here it says did:ex:1234.
Markus Sabadello:  And then there's a parameter called service 
  then did core defines that there is this parameter called service 
  and it defines a little bit what it means but did core doesn't 
  Define how you actually the reference this if you reference is 
  what exactly happens what exactly is the is the output and also 
  here for example if we have a fragment so that's missing in did 
  core.
Markus Sabadello:   Another thing that's missing is.
Markus Sabadello:  Concrete representations or data formats for 
  the did resolution results and the did URL dereferencing results 
  with all this metadata right in did core we we specify 
  representations and how to express a did document but we don't 
  really Define a data format or representation or serialization of 
  these other things that the metadata so this is also just 
  mentioned in an in an abstract way but.
Markus Sabadello:   Not is not really defined how.
Markus Sabadello:  How to implement it or what that looks like 
  then what's also not in in did core is some how you can invoke a 
  resolver how you can call a resolver so it doesn't Define a 
  binding over HTTP or over did comm over some other protocol 
  that's because did resolution is an is an abstract function right 
  it's not one it's not one single protocol as we have it in DNS.
Markus Sabadello:   For example in DNS.
Markus Sabadello:  There are DNS servers and their clients and 
  there's a well-defined client-server protocol and did resolution 
  is different because it's an abstract function and did core 
  doesn't actually Define how you can invoke or how you can call a 
  resolver so some of these things are.
Markus Sabadello:   Being addressed or.
Markus Sabadello:  We have been trying to fill in some of these 
  missing pieces some of these missing links in did resolution 
  specification which is a draft Community draft document it’s a 
  work item in CCG it's not a final specification but it's trying 
  to to add some of these missing missing pieces for example that 
  if it tries to Define more concrete algorithms so if you.
Markus Sabadello:   Resolve a did if you dereference.
Markus Sabadello:  A did URL then what exactly happens and here 
  just some some examples from from a some exemplary pieces of of 
  those algorithms for example here it says determine if the did 
  method of the input did is supported by the did resolver and if 
  not the data resolver must return the following result so you can 
  see here that.
Markus Sabadello:  The fact that there is did resolution metadata 
  and did document and did document metadata that's already in did 
  core and this error property that's also defined in did core and 
  the meaning of these things is also defined in did core but did 
  core doesn't actually you know provide an a concrete instructions 
  what happens when right if then else if the input is in a certain 
  way then there is all about.
Markus Sabadello:   A dereferencer should behave in a
Markus Sabadello:  Certain way and produce a certain output 
  here’s another example if the did URL contains a parameter called 
  service and the and maybe a parameter called relative ref then 
  the fact that these parameters exist and what they mean that is 
  in did core but did core doesn't tell us how to actually process 
  them and what the concrete outcome is if you dereference them and 
  some other things like what happens if you have fragments.
Markus Sabadello:   And and what errors are returned.
Markus Sabadello:  And so on so did resolution is trying to fill 
  in these more concrete algorithms and instructions it also 
  defines data format of the entire did resolution result and did 
  URL dereferencing results so in did core we only Define 
  representations of the did document but the other things did 
  resolution metadata did document metadata.
Markus Sabadello:   In did core only defines.
Markus Sabadello:  In an abstract in an abstract way but it 
  doesn't Define how you can represent the whole thing in Json or 
  json-ld I mean it's kind of obvious right if you if you look at 
  it it seems very straightforward and obvious anyway but still 
  it's probably something that should be explicitly defined.
Markus Sabadello:  Another thing that's in did resolution 
  specification is an HTTP binding or HTTPS binding how can you 
  call a resolver if that resolver is exposed as an as an HTTP 
  endpoint.
Markus Sabadello:  And here again it’s important to point out 
  that that this is not like DNS right where did resolution doesn't 
  have to happen by calling a remote service right so sometimes 
  sometimes people look at the Universal resolver for example 
  that's that's a relatively well-known project but this Universal 
  resolver project at DIF is run as a service as a remote endpoint.
Markus Sabadello:   And if you can call over an HTTP.
Markus Sabadello:  Binding but it's important to point out that 
  did resolution is this is just one way how did resolution can 
  work right did resolution can also just be an entirely local 
  process where you don't have to rely on any external service but 
  still in some cases it can be useful to have a binding or in this 
  case an HTTP interface to a.
Markus Sabadello:   Resolver and that's also one thing that.
Markus Sabadello:  We've been working on in the did resolution 
  specification you can see some some examples here it's it looks 
  relatively straightforward you basically it basically says that 
  you can execute HTTP get request and you're passing the did and 
  then you get back the did resolution result the did document plus 
  the metadata and.
Markus Sabadello:   The headers.
Markus Sabadello:  Play a certain role so you can use HTTP 
  headers and you can also pass additional parameters over the over 
  HTTP in the in the URL and and and this binding tries to map that 
  basically tries to map this http.
Markus Sabadello:  API to the abstract resolution and 
  de-referencing functions that are in the did core specification 
  and even though this looks relatively simple there are some there 
  are some details that are not so straightforward so for example 
  in in did core there is a difference between resolving a did and 
  dereferencing a did URLl.
Markus Sabadello:   And one question is.
Markus Sabadello:  If over HTTP if these two functions should be 
  if those two functions can be exposed at a single HTTP endpoint 
  or if you maybe want two different HTTP endpoints one for 
  resolving and one for dereferencing and how exactly do you pass 
  the resolution options how exactly do you get back the the 
  metadata to you map do you map the.
Markus Sabadello:   Options that you have on the did resoluatoin.
Markus Sabadello:  Level do you map those to http headers or do 
  you just send them in an HTTP body so there's some some details 
  that are.
Markus Sabadello:  Not as straightforward as it as it seems but 
  anyway this is also one of the things that we've been trying to 
  work on in did resolution specification one more thing there's 
  some sections a little bit of content about architecture so again 
  keeping in mind that did resolution implementations come in 
  different forms sometimes did resolution is just a local library.
Markus Sabadello:  Sometimes it's a remote service sometimes you 
  have a hybrid architectures where maybe you're running a did 
  resolve locally and it can resolve certain did methods locally 
  but if you can use a remote resolver as a fallback for did 
  methods that you cannot resolve locally and then there are always 
  a lot of questions about how you can trust the resolver and how.
Markus Sabadello:   How a client can verify if you get back the.
Markus Sabadello:  Correct result so there's a section also that 
  tries to discuss some of these some of these architectural or or 
  the topology how do different local and remote components.
Markus Sabadello:  Talk to each other.
Markus Sabadello:  And I don't know should I just keep going or 
  are there any any questions so far.
<manu_sporny> This is all great, keep going! :)
Harrison_Tang: I don’t see anybody in the queue so yeah please 
  keep going thanks.
Markus Sabadello:  Okay so so this so far has been on overview of 
  what's in the different specifications did core and did 
  resolution how does how those can relate and complement each 
  other and now I have a few slides about since this is called the 
  current state of did resolution I have a few slides about some 
  interesting topics that we've seen in the last few weeks.
Markus Sabadello:   And last few months.
Markus Sabadello:  What we are learning about did resolution or 
  what people in the community have been have been doing with with 
  these did resolution interfaces and so for example we've seen a 
  lot of extensions a lot of new ideas for resolution options for 
  did parameters for metadata properties and error codes.
Markus Sabadello:  And here's a list of some of these extensions 
  that there are not in did core and not in the did resolutions 
  specification but that have been defined Elsewhere for example 
  the parameter called initial state where you can pass on 
  information to a resolver about the initial content of the did 
  document there is a parameter called.
Markus Sabadello:   Transform keys where you can.
Markus Sabadello:  Instruct the resolver to convert the public 
  key representations in the did document let's say between an 
  ed25519 verification key 2018 you could convert it to a ed25549 
  verification key 2020 or to an adjacent web key so this is a 
  something that a resolver could could perform if it supports.
Markus Sabadello:   Some of these extensions.
Markus Sabadello:  A few new error codes have been proposed 
  method not supported that's not in did core but it seems useful 
  for a resolver to to indicate if it doesn't support a certain 
  method now internal error not allowed method not allowed 
  verification type invalid public key so I've seen several 
  proposals and and developments where a did resolver could be 
  considered a.
Markus Sabadello:  Point of where policies can be enforced and 
  where some kind of validation can happen how you could configure 
  did resolver in a way that it enforces certain policies where it 
  can accept or reject certain requests or certain things or 
  certain did methods depending on depending on policies of 
  depending on properties of those dids and did methods you could.
Markus Sabadello:   For example automatically.
Markus Sabadello:  Return an error if a weak public key is 
  detected in the did document right so the resolver could result 
  the did and then it could check all the public keys in the did 
  document and if those are considered weak or if a duplicate key 
  has been detected it could be considered an error or a warning or 
  a did resolver could automatically validate.
Markus Sabadello:   If the did document.
Markus Sabadello:  Conforms to the specification and if it's if 
  it's missing something there or if JSON LD context is missing or 
  if an ID value is invalid and then the resolver could also 
  indicate that performs some some validation.
Harrison_Tang: By the way Markus we have Sandy in the queue for 
  questions.
Harrison_Tang: Sandy we cannot hear you.
Sandy_Aggarwal: Okay I'm sorry how about now can you hear me okay 
  now.
Sandy_Aggarwal: Okay sorry for that so my question is and again 
  I'm sorry if this question has already been addressed earlier but 
  my question is so in confidence situations where you really need 
  to make sure that the resolver is dependable and it's not been 
  compromised is there any provision where you acquire the 
  signature of the resolver itself to be verified.
Markus Sabadello:  Yes that's the that has to do with with this 
  section here did resolution architectures there there is a 
  section about this in the did solution specification maybe 
  looking at that that last diagram here where you have a client 
  the client calls a local resolver using some library and then 
  that local resolver maybe calls a remote resolver over an HTTP 
  binding.
Markus Sabadello:   And then how can the.
Markus Sabadello:  Client be sure that that the resolver returns 
  the correct data and they're really at least two sub-questions or 
  subtopics that the first topic is does the resolver actually 
  retrieve the correct did document according to the did method the 
  second question is does the did resolver actually return that 
  same did document or does the did resolver manipulate the did 
  documents what the different.
Markus Sabadello:   Threat models and different attacks.
Markus Sabadello:  That can be considered what you mentioned that 
  the did resolver could sign the the result and return that to the 
  client that's one something that can certainly be done but that 
  is also mentioned in the in the specification but it's always 
  important to be aware of what does that protect from and what 
  does it not protect from right so if the did resolver signs the 
  result then.
Markus Sabadello:   It doesn't solve.
Markus Sabadello:  The problem of a potentially malicious did 
  resolver right so you that maybe prevent some man in the middle 
  attack or something like that where a client could verify that 
  the resolution result has been signed by the resolved and it 
  hasn't been manipulated since then but your but that doesn't 
  really solve the problem of is it really the right did document 
  for the for the did right so that's a separate question and there 
  are some considerations about.
Markus Sabadello:  That as well you could query multiple 
  resolvers and.
Markus Sabadello:  Compare the results or you could include in 
  the did resolution metadata you could include some State proofs 
  or some kind of method specific proof information which then the 
  client could independently verify but that that's what this 
  section is for to discuss and consider some of these topics that 
  come with different resolution architectures.
Sandy_Aggarwal: Right so so thank you Markus so I think like you 
  said I think the question I have is more not so much to prevent 
  the man in the middle attack but how do we make sure that the 
  resolver hasn't been compromised because it's very much possible 
  that the resolver may return correct data for some amount of time 
  you know to establish confidence but then when you know in a 
  different situation it may provide a different data so.
Sandy_Aggarwal:  I guess the question here begins and again.
Sandy_Aggarwal: My apologies if this has already been addressed 
  but the question here begins that does a resolver when you're 
  passing the did method over to the resolver can we necessitate 
  some sort of a signature verification that you know well I'm 
  indeed passing this on to or actually might be coming back from 
  the resolver as a part of that so so this for any response coming 
  back to the resolver is signed with a specific thing which is 
  already you know kind of.
Sandy_Aggarwal:  like signed with the resolver’s private key and 
  the public key is already there with the.
Sandy_Aggarwal: Requester with the client so this way the 
  requester knows that it's coming only from that resolver nobody 
  else.
Markus Sabadello:  Yes that that is certainly possible the 
  resolves can sign the result and then the client knows or can 
  verify that the result indeed comes from that from that resolver 
  but it doesn't solve the issue of of a compromised resolver if 
  the resolver itself is compromised then it could return a bad did 
  document and sign the bad did document and then the client knows 
  that that the result comes indeed.
Markus Sabadello:   From that resolver but the client still 
  doesn't know if it's been.
Markus Sabadello:  If the resolve itself is compromised or or 
  not.
Sandy_Aggarwal: Well it would right because I mean if the results 
  is compromised its signature is not going to be able to match so 
  obviously it’s gonna know you know any document signed by them 
  definitely will basically not be the same signature anymore.
Dmitri Zagidulin:  Markus do you mind if I jump in and add a 
  comment.
Dmitri Zagidulin:  I think the Sandy helpful thing to think about 
  with regards to resolver is that it is you must always consider a 
  trusted back-end architecture so your concern is correct but I 
  think you're thinking of the resolver more as an external as an 
  external component it is regardless of how its deployed it is 
  very much an internal trusted component so you have.
Dmitri Zagidulin:   To use the same.
Dmitri Zagidulin:  Techniques that you usually use to secure 
  other trust that internal microservices whether it's just IP 
  filtering whether you’re adding like OAuth2 authentication HTTP 
  signatures all of those techniques go but it is definitely a 
  trusted component thanks.
<kayode_ezike> Right, I see it as the difference between known 
  entity and trusted entity
Dmitri Zagidulin:  Yeah exactly exactly.
Sandy_Aggarwal: Understood thank you so you’re basically saying 
  Dmitri your point being that yes this I don't need the same you 
  know you know the umbrella and the you know circumference of 
  trust so you know that all right thank you thanks a lot.
Markus Sabadello:  Right so that the best scenario is probably 
  where you where the resolver is just a local library right so 
  where it's not even an a remote service that's that's probably 
  best also from a perspective of decentralization if the resolver 
  is up running locally and second best is probably if the if you 
  use a remote resolver that that you control or that that yourself 
  hosting.
Markus Sabadello:   And relying on a third party resolver.
Markus Sabadello:  Of course comes with some security and Trust 
  risks but.
Sandy_Aggarwal: Yeah if I may just leave too Food For Thought 
  here two thoughts here basically I'm going to essentially yes 
  agree in general like they distrusted circumference and is so 
  trusted you know you know basically ring-fenced sort of 
  environment but like the I guess we understand that there could 
  be compromised accounts and compromised keys and the second thing 
  is I think just from a future point of view I think how much of 
  this could.
Sandy_Aggarwal:  be Quantum safe and since that like we are 
  assuming that any any.
Sandy_Aggarwal: Public keys cannot be reverse engineered because 
  of the current you know encryption strengths but can we depend on 
  that for the next 10-20 years We don’t have to answer the 
  question right now but I'm just thinking out loud.
Markus Sabadello:  Yep good input thank you last comment I will 
  make just about these architectures is that like I said we think 
  of remote resolver with an HTTP interface just as one possible 
  way how you how resolution Works ideally resolution is just a 
  local process but there can also be other protocols and other 
  binding so for example.
Markus Sabadello:   We've also.
<harrison_tang> Sandy, we had some great discussions on 
  post-quantum cryptography earlier last year, and we plan to have 
  it again later this year
Markus Sabadello:  Specified at didcomm binding so you can also 
  call a resolver over did comm then you have all the security and 
  Trust benefits that you have maybe in in did comm including 
  mutually authenticated communication based on dids themselves so 
  you can use that also for communicating between resolvers okay 
  but the point that I wanted to make here on this slide is just 
  some some.
Markus Sabadello:   Innovation that that we’ve been.
Markus Sabadello:  Seeing recently on in terms of new parameters 
  options error codes functionality that a resolver can perform 
  we’ve already heard today about this recent proposal by checked 
  and some others I think that was also discussed on the ccg call 
  recently about the linked resources specification with some 
  proposed did parameters.
Markus Sabadello:  That can be included in a did URL in this case 
  to to identify a schema a resource with a certain name and type 
  and so this is also did URL dereferencing right so did resolution 
  and did URL dereferencing are really extensible mechanisms.
Markus Sabadello:  That can have where new functionality and new 
  potential behavior and outputs can be can be added and the trick 
  or the ambition of the did resolution specification is to provide 
  some framework or some generic algorithm that is pluggable and 
  extensible where anyone can any use case or any did method.
Markus Sabadello:   Or any application.
Markus Sabadello:  Can come up with their own ways of using did 
  URLs right so that we can add new functionality here's another 
  example we see in the work that's happening on decentralized web 
  nodes this is especially interesting I think because here's an 
  example of a did URL where one of the did parameters service is 
  already defined in did core whereas this one is an.
Markus Sabadello:   Extension that as far as I know.
Markus Sabadello:  Is defined by a decentralized web modes and so 
  service is a parameter that selects the service endpoint from the 
  did document and clear resistant something that's applied to the 
  decentralized web node that you find at that service so here's an 
  interesting way of using did URLs where part of the dereferencing 
  logic involves that the did document.
Markus Sabadello:   And another part of the logic involves the.
Markus Sabadello:  Service that you select from the did document 
  it's also interesting to mention that some of these parameters 
  some of the dereferencing logic tends to be did method specific 
  it only works with some did methods and whereas some of these 
  parameters are did method independent that work with all did 
  methods so there's a lot of logic and interesting functionality.
Markus Sabadello:   That can be done.
Markus Sabadello:  Here's some more examples of.
Markus Sabadello:  Some recent developments in in the area of did 
  resolution some did methods did:keri and did:self and version 2 
  of the did:ebsi.
Markus Sabadello:  What all of them have in common is that it's 
  not so easy to resolve the did unless you have some additional 
  information so for example this did:self or did:ebsi version 2 in 
  this case the method specific identifier is a JW key jwk 
  thumbprint so that means you cannot resolve this to a did 
  document unless you already.
Markus Sabadello:   Have the did document and some other 
  information.
Markus Sabadello:  We've been discussing this on different calls 
  and different communities because this this feels really strange 
  right we are used to we're used to the idea that if we have a did 
  we can immediately resolve it we just go to to a web server or to 
  a block chain or to some API and we we retrieve the did document 
  for the did whereas here the dids require some additional 
  information so you.
Markus Sabadello:   Basically already need the did document in.
Markus Sabadello:  Order to be able to resolve the did document 
  that sounds really strange but I think it it actually fits into 
  the framework I think it's totally legitimate to do these things 
  it just means that when you call the resolver you have to pass 
  the did plus additional resolution options right and that's then 
  depends on the did method but it still fits into the overall 
  overall framework of dids and.
Markus Sabadello:   The same is true for did:keri.
Markus Sabadello:  So keri is getting something that's getting a 
  lot of attention to key event receipt infrastructure a new 
  innovative way of managing keys and and in this in this 
  technology you have an identifier and there's also not 
  immediately immediately a way to resolve it you need you 
  typically need something.
Markus Sabadello:   Called an oobi.
Markus Sabadello:  And introduction which lets you discover 
  Witnesses and Watchers I'm not an expert on keri but but also 
  here the identifier is not enough and so you need to Define some 
  additional parameters and additional options in order to be able 
  to resolve it so I think this is also quite.
Markus Sabadello:  Interesting to have the new ways of innovative 
  did methods.
Markus Sabadello:  And I'm almost done here is the third slide 
  that yes as we work on did resolution we are encountering again 
  some maybe not so not so easy topics from that we already had in 
  the did working groups on uncertainties unanswered questions 
  maybe around different representations and media types there.
Markus Sabadello:   Was a.
Markus Sabadello:  Github issue where a media type of Manu opened 
  a I think about on the did core specification about how to handle 
  media types for example in the in the did Web method so what 
  we're seeing here is.
Markus Sabadello:  If you resolve a did.
Markus Sabadello:  Web identifier then typically the resolution 
  process looks like this where you retrieve a.
Markus Sabadello:  Document called did.json over HTTP and then in 
  many cases this will be on the HTTP level this will be returned 
  as application/json but it includes @ context sorry this is wrong 
  this @ context is wrong this should actually be the standard the 
  standard did core context but anyway you get back a did document 
  in json-ld form with an.
Markus Sabadello:   Application/json header but then this is not.
Markus Sabadello:  Really one of the media types defined in the 
  did core specification which defines these media types so there's 
  a.
Markus Sabadello:  Little challenge here I wonder if maybe the 
  did resolution work can make some of these easier but but anyway 
  also something to be.
Markus Sabadello:  Aware of and then last slide so what's now the 
  current state of this did resolution as I said it’s a work item 
  in the ccg it's a draft Community report like I said it covers 
  some algorithm some data format some extensions some 
  architectural considerations it is definitely.
Markus Sabadello:   Not done so.
Markus Sabadello:  It needs more work it probably some things 
  need to be added some things need to be fixed there are 45 open 
  issues.
Markus Sabadello:  There is also the test Suite so we contributed 
  that a few months ago a did resolution test Suite which is 
  different from the did test Suite right so there's a did test 
  suite that test the did core specification and the idea of the 
  did resolution test Suite is to test the did resolutions 
  specification there is some overlap but it's really.
Markus Sabadello:   A little bit different with this you can.
Markus Sabadello:  Test a resolver endpoint and see if it behaves 
  correctly.
Harrison_Tang: By the way Markus we have Ryan on the queue for 
  questions.
Markus Sabadello:  Yeah just that the last thing this is really 
  the last thing how there is now a proposed Charter for the next 
  did working group and that says that the working group will begin 
  working toward a specification for did resolution and did URL 
  dereferencing so that's a place where this work can hopefully 
  continue.
Markus Sabadello:  That's it thank you and yes more questions.
Ryan Grant:  Hi Markus thank you very much I have a question it 
  seems there are different requirements for different resolver 
  deployment architectures so how could the did resolution 
  specification prioritize between on the one hand Clarity of 
  specification for a simple architecture as may be required to 
  move the did working group past a privately threatened formal 
  objection versus convenience features.
Ryan Grant:   For certain network reliant architectures.
Markus Sabadello:  I think I don't think the did resolution 
  specification should have a lot of requirements that depend on on 
  the architecture I think everything that it.
Markus Sabadello:  It says and mentions about for example the 
  algorithm how are how is the did URL processed when there are 
  certain error codes returned how is the metadata being used I 
  don't think this has much to do with the architecture doesn't 
  make much of a difference if it's an entirely local resolver or 
  it's a remote resolver there is a section about these 
  architectures.
Markus Sabadello:  The did resolution specification but those 
  sections
Markus Sabadello:  Don't really change the behavior or the 
  algorithms or their requirements of how how did resolution really 
  works it just adds on security considerations and Architectural 
  considerations and it's not finished right so if you actually 
  look at the document you will see a lot of open open issues and 
  and ideas that still have to be.
Markus Sabadello:   Completed but I'm.
Markus Sabadello:  Not sure exactly what you mean about 
  preventing formal objections too can you specify.
Ryan Grant:  Sure I think one of the ways that the did working 
  group could could move forward as discussed at TPAC would be to 
  focus on did resolution and the threatened formal objection that 
  I referred to was the prior formal objections and and that they 
  would be repeated if there was not a did method chosen but.
Ryan Grant:  There is not consensus on choosing a did method so I 
  was asking what kind of the minimal set of.
Ryan Grant:  Of clarity of specification would be in for instance 
  does does did resolution spec need to choose an example 
  architecture that it answers certain questions for in order to 
  dissolve the formal objections.
Markus Sabadello:  Well first first I don't think the did 
  resolution specification should mention any specific did method 
  so I know that there is a ongoing discussion whether or not a new 
  did working group should standardized did methods and if yes 
  which ones or no did Methods at all I consider that completely 
  separate and independent from the did resolution specification 
  the did resolution specification should.
Markus Sabadello:   Not mention any specific did method.
Markus Sabadello:  It should also not do anything or make any 
  assumptions that would favor certain did methods or certain did 
  method architectures when when I mentioned architectures here I 
  meant not architectures of the did methods so it's not about did 
  web versus a did key versus blockchain based.
Markus Sabadello:   Did method this is more.
<rgrant_ryan> agreed that DID resolution should not mention DID 
  Methods.  But in order to have an alternative way forward in 
  DID_WG, the features that DID Resolution can provide become more 
  important.
Markus Sabadello:  About the architecture of the of the resolver 
  right is the resolver hosted locally is the resolver hosted at an 
  HTTP endpoint but this has nothing to do with with how the did 
  method works and I think they should be completely neutral and 
  not not do anything that that favors or makes any assumptions 
  about how the did method itself works.
Ryan Grant:  If I could just tag on to perhaps clear up any 
  misunderstanding I wasn't trying to bring that into into this 
  specification the direction of my question was that this 
  specification could become more important as one way to dissolve 
  the roadblock in the did working group in a way that also.
Ryan Grant:   Satisfies other concerns about.
Ryan Grant:  Not picking did method winners and losers so if this 
  did resolution specification was becoming more important then my 
  question would be is it helpful to to pick a deployment 
  architecture as an example implementation so that people who 
  would otherwise formally object such as a prior formal.
Ryan Grant:   Objectors.
Ryan Grant:  See that it is clear what packets need to be sent 
  over the wire to or not over the wire if we choose a different 
  deployment architecture in order to fully.
Ryan Grant:  Result get a resolution from a did that’s all.
Markus Sabadello:  Yes I mean I think this is something that the 
  specification could could discuss something that has a little bit 
  of that already here in this section it does mention and 
  illustrate with with diagram certain deployment architectures if 
  you want then try to discuss a little bit what are the risks and 
  potential threats of certain architecture so to.
Markus Sabadello:  I don't know maybe a maybe I can take the 
  universal resolver as an example if you go to uniresolver.io 
  that's a relatively well-known service in the community and a lot 
  of people use that but you should not use that except for 
  experimentation maybe because it is a.
Markus Sabadello:   Third party hosted.
Markus Sabadello:  Service that could be unreliable that could 
  manipulate the results and so this kind of thing this this I 
  think would be would be in scope to to discuss and describe a 
  little bit these different architectures is is that what you mean 
  or.
Ryan Grant:  Yeah I'm just asking questions about what this this 
  specification could do to prioritize in a way that would make it 
  a viable answer for for finishing it in the did working group and 
  as as the current did working group charter specifies the 
  proposed charter.
Harrison_Tang: Cool any other questions for Markus.
Harrison_Tang: All right thank you Markus thanks for your great 
  presentation on the DID resolution.
<manu_sporny> Thanks Markus!
Harrison_Tang: One quick question for David David you mentioned 
  you would like to talk about evidence properties I'm just 
  wondering you know how long will that take and also do you want 
  if it's long then we probably should put that in the agenda.
David Chadwick:  Yeah, well actually, I won’t be here next week. 
  I’m traveling. But basically there is a draft and all we’re 
  wanting to do is to standardize what the type would be. Because 
  as you know, the verifiable credential allows any evidence to be 
  specified of any type, and so we’d just like to standarize one 
  type, which refers to the Open ID Foundation’s existing draft 
  specification on identity assurance. So they’ve actually, there’s 
  been a working group working for a year or more on how do you 
  assure identity and what evidence do you need to assure identity? 
  So we’ve got a whole standard on this and we’d what like to do it 
  import it into verifiable credential by saying if you have this 
  particular type of evidence, then it means you’re using the Open 
  IDF standard for evidence. That’s essentially it, the new work 
  item.
Harrison_Tang: Got it okay maybe I can coordinate with you over 
  email offline and then perhaps we could even get the open ID 
  folks to join our meetings to kind of describe this topic a 
  little bit further.
David Chadwick:  Yeah, what really interesting that came out of 
  it actually is that when presenting evidence, they’re actually 
  presenting a whole raft of evidence. So if you consider 
  somebody’s name, their evidence might be “I took the name David 
  Jones from the passport, and I took the name David Jones Smith 
  from their driving license” and now you’ll see that you’ve got 
  different evidence with different names because over time, 
  someone might have changed their name or by deep pull or 
  whatever. And so, there are two things that come out here - one 
  is the evidence value, the evidence value is presented then not 
  by the same as the actual value in the verifiable credential 
  because of changes to them, and the second thing is that the 
  evidence is somehow duplicating information in the verifiable 
  credential such that if you were to do selective disclosure of 
  the verifiable credential, but not selective disclosure of the 
  evidence, you may actually be revealing evidence, information 
  that you didn’t want to reveal in the selective disclosure. So 
  that’s a really interesting thorny problem to discuss.
Harrison_Tang: Thank you thanks alright well we're almost at time 
  any last announcements reminders or introductions and 
  reintroductions all right thanks a lot have a good one bye.
Received on Wednesday, 18 January 2023 11:15:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 18 January 2023 11:15:23 UTC