[MINUTES] W3C CCG Verifiable Credentials API Call - 2022-10-04

Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:

https://w3c-ccg.github.io/meetings/2022-10-04-vcapi/

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/2022-10-04-vcapi/audio.ogg

----------------------------------------------------------------
VC API Task Force Transcript for 2022-10-04

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2022Oct/0008.html
Topics:
  1. Community Updates
  2. Snapshot VC API for VCWG?
  3. Credential Revocation/Status Configuration
Organizer:
  Manu Sporny
Scribe:
  Our Robot Overlords
Present:
  Manu Sporny, Brian, Patrick (IDLab), TallTed // Ted Thibodeau 
  (he/him) (OpenLinkSw.com), Dmitri Zagidulin, John Kuo, Mike 
  Varley, Joe Andrieu

Our Robot Overlords are scribing.
Manu Sporny:  Alright welcome everyone to the October 4th 2022 
  verifiable credentials API call our agenda is here and on the 
  agenda today we've got this review introductions reintroductions 
  any relevant Community updates then looking at the question of 
  snapshotting the VC API for the verifiable credentials group.
Manu Sporny:  We're also looking at the credential revocation 
  status configuration issues looking at the internal versus 
  external API language in that kind of stuff and then processing 
  any other issues as time might permit are there any updates or 
  changes to the agenda that folks would want to cover today.

Topic: Community Updates

Manu Sporny:  Okay if there are none let's go into introductions 
  reintroductions in community updates is there anyone new here I 
  think we all know each other anyone want themselves.
Manu Sporny:  If not we can go into Community updates any 
  Community updates that folks would like to share last week was 
  rebooting the web of trust there were a number of really 
  interesting paper submitted in one's worked on there I think 
  we'll try and type up a summary of what happened last week in 
  share it with the ccg mailing list and so look for look for that.
Manu Sporny:  Hopefully in the next.
Manu Sporny:  Things that moved forward that might be of use to 
  us here was this concept of authorized issuers or known 
  authorities so like issuers that are well-known or verifiers that 
  are well-known and using those values in ways when you do a 
  validation of a verifiable credential so do you actually.
Manu Sporny:  His driver's license was issued by the relevant 
  Authority or that this permanent resident card was issued by 
  relevant Authority or this library card was issued by you know a 
  university unknown University things like that other things that 
  happened there Dimitri Bango in Charles Lander did some really 
  good work on rendering.
Manu Sporny:  There was a number of items covered that had to do 
  with Selective disclosure and when it's appropriate to do 
  selective disclosure and when in might not be and where certain 
  types of correlation can happen correlation can happen with data 
  that you provide or it can happen when you use certain systems or 
  it can happen in back-end systems so variety of things of of 
  that.
Manu Sporny:  You were discussed there there were a lot of cool 
  demos that that happened there will be some video released around 
  that trying to think of anything else that might be oh Demetri 
  and Phil Long in those folks took a look at kind of cryptographic 
  hyper linking like the ability to link a current resource to a.
Manu Sporny:   A remote.
Manu Sporny:  Source in the verifiable credential so that was you 
  know looking at more more formalization around that concept and 
  that were moved forward so the way rebooting works is that now 
  all the teams are going to work for a couple of weeks to clean up 
  their papers and then they'll be published as rebooting papers 
  and then once that happens that work might be fed into the 
  credentials community.
Manu Sporny:   Group or diff or a variety of other.
Manu Sporny:  Organizations and eventually potentially be taken 
  standards track are there any other items that folks that were at 
  rebooting I wanted to cover anything else that we should mention 
  that might affect be Capi.
Joe Andrieu:  Sure I have a comment.
Manu Sporny:  Please go ahead.
Joe Andrieu:  So the paper that I ended up contributing to was 
  based on using Merkle trees to issue credentials to groups that 
  at least was one of the primary sort of defining use cases and as 
  we tease it out there were some interesting implications for 
  fields that need to go into the verifiable presentation and also 
  how do we present the guidance for validation that you are a 
  member.
Joe Andrieu:   Of the group and we were.
Joe Andrieu:  Out like is that a separate proof is there a proof 
  for tamper evidence versus proof for membership and we were 
  trying to tease out and I think it aligns with some of the 
  conversation that Oliver's engaging in about how do we provide 
  guidance for people at the validation stage so I think there's 
  going to be some suggestions there for the VC WG not sure if it's 
  going to affect the API but it's definitely a sort of a different 
  flow than some of the other use.
Joe Andrieu:   Aces we've been talking about.
<manu_sporny> IIWXXXV FALL 2022: NOVEMBER 15, 2022 – NOVEMBER 17, 
  2022: https://internetidentityworkshop.com/
Manu Sporny:  Yep yeah good good point thank you for that Joe 
  okay with that I think we can well the other thing is the the 
  next event that's coming up is internet iiw 35 I guess I'll put a 
  link for that here November 15th through the 17th there is going 
  to be.
Manu Sporny:  Is he there.
Manu Sporny:  Dated to the jobs for the future plugfest and that 
  plugfest there a variety of companies that are using the 
  verifiable credential API to do issuing so we've we're already 
  getting some signals from the market that there are a number of 
  implementers that are using the VC API to do issuing for that 
  plugfest so that's interesting and so the day before iiw will be 
  kind of the plugfest report out so.
Manu Sporny:   All the plugfest stuff.
Manu Sporny:  Month and then during bit of the day before is the 
  official plugfest kind of demo event and then I'm sure we'll hear 
  about it throughout the internet identity Workshop okay I think 
  that's it for Relevant Community updates anything else that folks 
  want to comment on before we move on.
Manu Sporny:  Go ahead battery.
Patrick_(IDLab): Yeah it's just not as exciting as the the event 
  of the last week in the updates but I made a proof-of-concept 
  available for sort of Aries Cloud agent this API coordinator 
  application if I can call it so so it's basically a open API with 
  all the paths that are defined so far I've sort of combined the 
  verifier issuer and a holder paths and one.
Patrick_(IDLab):  application and some of the endpoints.
Patrick_(IDLab): And they leverage our Aries agent to do the 
  logic so I thought I'd share this.
Patrick_(IDLab): It's a very interest.
Manu Sporny:  Yeah that's that's really cool Patrick would you 
  mind doing an announcement on the public credentials mailing list 
  about that I think there'd be a variety of people that are 
  interested in that I I'm pretty sure you're the first person that 
  has done that kind of bridging.
<mike_varley> yes! please post to the list.
Patrick_(IDLab): I was presenting it earlier today was the Acca 
  Thug can we use a group which is the Aries Cloud agent python it 
  was one attendant that said he he did give it a go but quite some 
  time ago I think it was before the sort of the change in the test 
  Suite he said it was Africa but some time ago and I know there 
  was also a lot of interests if this gets mature not to sort of.
Patrick_(IDLab): Because the area.
Patrick_(IDLab): Jen does have.
Patrick_(IDLab): API available for the admin interface and there 
  was an interest if it gets mature enough to implement this in 
  Aries itself in the admin API so yeah that was also something 
  that the community was potentially interested in doing.
Manu Sporny:  Yeah there's the feels like there's a bridge there 
  that could be built which is always a useful thing so yeah if you 
  don't mind sending you just something out to the public 
  credentials mailing list about it I'm sure there's going to be 
  interested in that and I see Mike Farley also suggesting you know 
  please post that to the mailing list okay any other updates 
  relevant Community updates.
Manu Sporny:   Of that nature.

Topic: Snapshot VC API for VCWG?

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/304
Manu Sporny:  All right let's go ahead and get into our main 
  agenda item for this week so the first question is whether or not 
  we should snapshot the verifiable credentials API for the 
  verifiable credentials working group that is this issue 304 let 
  me go ahead and.
Manu Sporny:  And then open this one.
Manu Sporny:  Um so we touched upon this topic two weeks ago 
  before rebooting the web of trust there's been some amount of 
  discussion most of it today on the issue and so the the question 
  is do we feel like some subset of the verifiable credentials API 
  is ready to be kind of published as a preliminary like draft note 
  just in editors draft.
Manu Sporny:  It's the intention of it being a note in the 
  verifiable credentials working group specifically it would be a 
  subset of what we're working on as there's been some pushback to 
  doing the whole document so the note will specifically provide 
  the verifiable credential API calls necessary for generating a VC 
  generating a verifiable presentation verifying both verified 
  credential and a.
Manu Sporny:   Sighing verified.
Manu Sporny:  Presentation and checking the status of a 
  verifiable credential so it will specifically not include the 
  exchanges section of the document I think that's the current 
  proposal we've got a plus one I think from Maven net a +1 from 
  Danube Tech.
Manu Sporny:   It is so.
Manu Sporny:  Of so there is a lot of clarification that happened 
  here between these two comments here so transmute wanted the 
  presentation stuff in there they wanted the ability to check 
  status lists or revocation lists they did not want to do the 
  exchange part because their contentious flavors of that and that 
  might just.
Manu Sporny:   Start a fight in the group.
Manu Sporny:  Which you don't necessarily want to do at this 
  stage let's see did not want references to other CG drafts to get 
  dragged along did not want VC jot to be excluded.
Manu Sporny:  Make sign presentations or the ability to check 
  credential status so there are some clarifications made and 
  language updated in the original proposal in that got thumbs up 
  from ory and Mike Farley from a vast and Dan UTech and Mike 
  Farley here look like looks like you're supportive of The 
  Proposal with the corrections let me stop there they the I think.
Manu Sporny:   The challenge a couple of.
Manu Sporny:  Was that people seem to not be clear about what 
  exactly we would be publishing and we said we'd put aside some 
  time to discuss it now that people have had a couple of weeks to 
  think about it what are the current thoughts concerns things of 
  that nature if.
Manu Sporny:  Go ahead and put yourself on the Queue if you if 
  you have any.
Manu Sporny:  Go ahead Mike.
Manu Sporny:  Yeah it's not even conformance thing it's just like 
  here's a thing that a couple of people in the working group wrote 
  and published and it doesn't mean that it has consensus or 
  agreement or anything like that people just thought it was a 
  useful thing to publish sometimes work well usually sorry no let 
  me back that off sometimes.
Manu Sporny:  In groups publish notes with the intention that 
  they could be taken standards track in the future so this you 
  know when we publish the note the note can be used to do 
  implementations and advisory things and then in the future the 
  working group in a recharter could decide to take VC API to a 
  standard or it could choose to not do that.
Manu Sporny:  Great thanks Mike Patrick you're on the.
Patrick_(IDLab): I just want to know if you question it depends 
  on the field the endpoint it's got to do with the description of 
  the end point for example the end point presentations verify the 
  description says very very presentation with or without proofs 
  attached and is there something I'm not understanding or in order 
  for a presentation to be verifiable it needs to have a proof.
Manu Sporny:  Yes that's a great observation I am totally 
  forgetting why we put that language in there so which let me see 
  it's in the verifying presentation part.
Patrick_(IDLab): Yeah well there's a in a few places but yeah 
  that would be the most blatant example so presentations verify 
  from the verifier.
Manu Sporny:  Yeah there was a there was a point in time where I 
  think we said well this endpoint is just for verifying a 
  presentation and the presentation does not necessarily need to 
  have a proof attached to it so you can make a presentation 
  without any signature on it you can also present a credential 
  without a signature on it.
Patrick_(IDLab): But what would the how would that get verified 
  like what.
Manu Sporny:  For example if you had a presentation that was not 
  a verifiable presentation but it contained a verifiable 
  credential in it it you it's effectively a bearer instrument so 
  presenting a movie ticket would be an example of a presentation 
  of a bearer token so the verifiable credential would be the movie 
  ticket and it it would be digitally signed by the movie theater 
  company.
Manu Sporny:   But the.
Manu Sporny:  In itself if the credential was not bound to any 
  any you know cryptographic key then you could just provide a 
  presentation with the verifiable credential that signed in it and 
  that would be an example of verifies the presentation without a 
  proof and Returns the verification result in the response body.
Patrick_(IDLab): So does that mean it would verify the credential 
  instead and that case.
Manu Sporny:  Theoretically yes I think we still don't quite we 
  haven't formalized that to in a appropriate level so the theory 
  is yes that's what would happen but in practice we need more 
  implementation feedback.
Manu Sporny:  Correct yep that's right.
Patrick_(IDLab): Okay and my other question is which is the exact 
  on the same sort of thing so and on the holder side of things for 
  example so when you do a get request on the can the credential 
  this says you get a list of credentials or verifiable credentials 
  what is a credential that is not verifiable are we just talking 
  about the credential without a proof in this case okay.
Manu Sporny:  Yep it's a credential that has no signature on it.
Patrick_(IDLab): But it is still strictly the w3c data model we 
  are referring to here.
Manu Sporny:  Yes correct yeah the VC data model I if I remember 
  correctly has a the concept of a credential and a verifiable 
  Prudential yeah and I think it's in the definition of it so if we 
  look at terminology you know a credential is a set of one or more 
  claims made by an issue or a verifiable credential is 
  tamper-evident so on and so forth right and I believe the same 
  thing yeah exist for a press.
Manu Sporny:   And Tatian Data Drive from one or more.
Manu Sporny:  He sees I should buy one or more issuers shared 
  with the verifier and then we Define what a verifiable 
  presentation is there.
Patrick_(IDLab): So that was just yesterday the presentation but 
  if I would be the only thing I would consider clarifying before 
  submitting a sort of note to her I don't know how you called it 
  oh yeah.
Manu Sporny:  So to be clear we can update this stuff a note is 
  just like a point in time can be a point in time snapshot and I 
  think that's all we're intending right now we can update this at 
  any point and the expectation is we will be updating this you 
  know throughout.
Manu Sporny:   The next.
Patrick_(IDLab): Forever maybe not forever but.
Manu Sporny:  You know once years whatever yeah yes yes forever 
  yeah hopefully at some point we're done with it but yeah for the 
  foreseeable.
Patrick_(IDLab): Okay and if I cannot Also regarding the 
  responses are these all required and do they all serve a purpose 
  or there's just been a few that was filmed in there just in case.
Manu Sporny:  Yet to be determined so clearly like it looking on 
  the screen here we've got you know someone was being queued and 
  put 418 I'm a teapot right like that's not something we should 
  have in the spec but we do need to cover for each one of these 
  things will need to go and see if these are appropriate error 
  codes and whether or not every single ones required.
Manu Sporny:   Or if.
Manu Sporny:  You know only some of them are required.
Patrick_(IDLab): Yeah and we didn't make sense in the get request 
  credential to have like a 44 if there is a little more like get 
  credentialed with the ID to have a 44 or is that yeah okay.
Manu Sporny:  Yeah yeah exactly yeah exactly and that's that's an 
  example of one that's missing here I don't think we've put a 
  tremendous amount of effort into the looking at each one of the 
  endpoints and making sure that the response codes are you know 
  correct.
Patrick_(IDLab): Yeah that's fine so I can think about that 
  because when I was making the my Swagger all my open API wasn't 
  sure if I needed to absolutely like copy as it is exactly or if I 
  could the include like if you like the for for for example.
Manu Sporny:  Izzy a certainly I wouldn't I wouldn't look at 
  anything that we're doing as anything other than like 
  experimental and in movement right now so yeah do not take this 
  as a final anywhere near close to the final specification there's 
  still a lot of work that needs to go into it.
Manu Sporny:  Any other questions or concerns about moving this 
  into the verifiable credential working group but one concern I 
  have is that we may want.
Manu Sporny:  More of a Capi implementers to put their name on 
  this and so maybe we want to reach out to some of them to see if 
  they're okay with this being pushed in in the BC working group 
  because I think right now we have one two three four five 
  implementers that are supportive of it.
Manu Sporny:  And that have implemented to the API and that's and 
  by the way that's like more than enough to actually get all the 
  way through the recommendation process if if we were on that 
  track and we're way way before having to do that so there seems 
  to be enough implement or interest for this right now and you the 
  minimum is you need to interoperable implementations and we're 
  well past that at this point.
Manu Sporny:  Okay any any concerns around the framing here if 
  not we could prepare a snapshot that could be taken.
Manu Sporny:  To the VC working group as a proposal.
Manu Sporny:  Okay the we Capi.
Manu Sporny:  Okay and one thing that we're going to have to do 
  is.
Manu Sporny:  We're going to have to I don't know how this is 
  done I don't think we publish a final community group 
  specification or if we do.
Manu Sporny:  It's like of a particular version or something like 
  that I'll have to maybe it's a final community group 
  specification of a point release like version 0.8 or something 
  like that.
Manu Sporny:  Um okay anything else on this topic before we move 
  on.
Manu Sporny:  So this one was say ready ready for PR.
Manu Sporny:  Like it taken action to do this one.
Manu Sporny:  Next steps are to create General location is.
Manu Sporny:  I need to meet your specification and then.
Manu Sporny:  Okay so that's that item all right next up is.

Topic: Credential Revocation/Status Configuration

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/264
Manu Sporny:  Credential revocation and Status configuration 
  there two issues here.
Manu Sporny:  Let's the cell and let's open to 64 and 141.
Manu Sporny:  Okay so this one has to do with the verification 
  method of a revocation list must match the issuer of verifiable 
  credential this is basically saying don't digitally sign the 
  revocation list with a different value sorry with a different key 
  than sorry don't sign a revocation list with a different type of 
  cryptography.
Manu Sporny:   Geography than.
Manu Sporny:  The verifiable credential you issued so don't sign 
  for example don't sign a revocation list with with SEC P 256.
Manu Sporny:  And then sign the credential with Edie 255 119 so 
  so basically to 5519 so basically don't mix and match crypto 
  between a revocation between the credential and the revocation 
  list in which that credential is stored we had thought we had a 
  discussion about this a while ago maybe we did.
Manu Sporny:   Did not.
Manu Sporny:  So this is a request for the VC API to specify that 
  these two things should match up well or he's saying they must 
  match up there may be a counter proposal that they should match 
  up but we may not want to make it absolute.
Manu Sporny:   For example.
Manu Sporny:  You're trying to do cryptographic layering you 
  might want to digitally sign a list with two different values.
Manu Sporny:  Okay so all that said it oh the other the other 
  thing that goes into this issue is that we have in the past made 
  Let's see we have.
Manu Sporny:  Decided that it is okay for a different issue or 
  endpoints to be pre-configured with a variety of different values 
  like which crypto sweet they should use which type of revocation 
  list they should use whether or not the credentials should be 
  revocable all that kind of stuff goes in as a kind of a 
  configuration for an issuing endpoint and so an extra thing that 
  we could do is say that for that endpoint.
Manu Sporny:   Ain't we.
Manu Sporny:  Either you either must make sure that the crypto 
  sweets are the same or you should be sure that the crypto sweets 
  are the same let me pause there to see if anyone has any 
  suggestions on how we might implement.
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Something 
  with solid cube.
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Wondering how 
  this will play out with crypto method that's broken.
Manu Sporny:  Yeah it's a good question so basically.
Manu Sporny:  If you always keep these things one to one if that 
  one crypto meth you know crypto sweet is broken your revocation 
  list in your credentials broken as well so that's one option 
  another option is that you could use this New Concept called 
  cryptographic layering so let me try and data Integrity let me 
  linked to the concept.
Manu Sporny: 
  https://w3c.github.io/vc-data-integrity/#agility-and-layering
Manu Sporny:  Here is this so the concept of cryptographic 
  agility and cryptographic layering so the idea behind 
  cryptographic layering is that you employ multiple personality 
  rhythms at the same time in parallel to protect the data so you 
  would digitally sign using like a pre Quantum cryptography sweet 
  and a post Quantum cryptography cryptography sweet at the same 
  time so that.
Manu Sporny:   A tiff.
Manu Sporny:  One of those Cryptids weeds fails you've got the 
  protection of the other Cryptids sweet so that's an sets the 
  second option and then the third option is to use a different 
  cryptography sweet to protect the revocation list then the 
  credential but then if you have a failure whichever thing failed 
  like the whichever cryptic sweet failed on either the the 
  revocation list.
Manu Sporny:  Of the credential you would not be able to.
Manu Sporny:  Kind of the security in the system so they're kind 
  of three options that were looking at right now Joe you're on the 
  queue.
Joe Andrieu:  Yeah I was a little confused by the reference going 
  from 264 over to the configuration of the endpoints but in the in 
  the case of 264 if that's what the question is still about it 
  seems that other verification methods in the same decentralized 
  identifier should be valid such that the the did document can 
  provide multiple ways to verify the list.
Joe Andrieu:   I think the key thing is that.
Joe Andrieu:  Identifiers and that allows this sort of 
  cryptographic agility overtime for different crypto sweet 
  mechanisms so maybe I could support a should on this but must 
  definitely feels over constraining given the flexibility we're 
  going to need over the lifetime of the credentials were dealing 
  with.
Mike Varley: +1 Joe
Manu Sporny:  Yep good point let's see this was just.
Manu Sporny:  Any other thoughts on this micro he's giving you a 
  plus one Joe any other thoughts on what we should do here.
Manu Sporny:  So let's see this was I can I can start writing 
  down kind of what was discussed uh.
Manu Sporny:  Yo is your is what you're saying the that the so 
  like you know a signature has a verification method that it's 
  tied to and so are you saying that as long as the did method.
Manu Sporny:  Ports the same kryptos we are you said I don't know 
  which one of these three options I guess you were referring to.
Joe Andrieu:  Yes I don't think the crypto sweet matters at all I 
  think what matters is that that did has been updated to have a 
  verification method that signs the revocation list I think the 
  fact that we can change verification methods for an existing did 
  is the is an important level of flexibility that we would lose 
  here.
Manu Sporny:  I don't know if what you're saying makes sense so 
  dids don't have revocation methods associated with them they have 
  kryptos needs okay.
Joe Andrieu:  Every kid verification methods that in fact I would 
  argue they don't have kryptos weeks I've been confused by that 
  language throughout this conversation so the the did that is 
  indicates the creator of a signature needs to be the did that 
  signs the revocation list I think that's correct but if we were 
  to say once you sign a VC you can only ever sign a revocation 
  list with the verification method for those VCS that feels like.
Joe Andrieu:   A pretty arbitrary.
Manu Sporny:  It's about saying once you sign the VC and the 
  revocation list you can't change.
Joe Andrieu:  And I know it's with with or he's proposal signing 
  the VC with a given verification method would prevent you from 
  changing the verification methods in that did document and and 
  still have it work.
Manu Sporny:  You don't want to tie a yeah yeah yeah.
Joe Andrieu:  It would it would deny rotation.
Joe Andrieu:  And I think rotations valuable.
Manu Sporny:  Yeah yeah yeah.
Manu Sporny:  But dids shouldn't be restricted from rotating 
  their verification methods therefore these values are for the 
  verification method likes drift over time okay.
Manu Sporny:  Yep good point.
Joe Andrieu:  Yeah I like should I think it's a good practice.
Manu Sporny:  So do we want to say that.
Manu Sporny:  Implementers should use the same.
Manu Sporny:  Yeah implementers should use the same verification 
  method to.
Manu Sporny:  Protect both the VC and the revocation list if 
  possible.
Joe Andrieu:  Yeah I would I would say issuers rather than 
  implementers.
Manu Sporny:  Okay it's yours should should use the same time 
  using the same verification method.
Manu Sporny:  Put maybe multiple to protect protect both the 
  verifiable and chill as well as the revocation list if possible.
Manu Sporny:  I guess should implies if possible.
Manu Sporny:  As a best practice that's that sound as a britisher 
  should use the same verification methods to protect both the 
  verifiable credential as well as the revocation list I go ahead 
  Patrick.
Patrick_(IDLab): What are we talking about verification methods 
  here are we referring about the crypto sweet that's being used.
Manu Sporny:  There is a link let me try and draw the link.
Patrick_(IDLab): If I can maybe the so that the other part of my 
  question was I remember a few called ago you said like one 
  organization can have many implementation and it could be 
  preferred that one implementation his use strictly one crypto 
  sweet is this related to could this be related to that comment or 
  it's a different.
Manu Sporny:  Yes it's it's it yeah it's it's related in some way 
  we haven't figured out to what degree it's related so in theory 
  you know what you what you would do is you would set up this 
  verifiable credential API and then you would configure an 
  endpoint to use a very specific set of verification methods to 
  create digital proofs in those verification methods are.
Manu Sporny:   Associated with.
Manu Sporny:  It and so you're basically telling the end point 
  when you create a digital signature here's the cryptographic 
  material in the Crypt is sweet that you should be using and then 
  everything it issues from there on out we'll use that in if we 
  use the language here where we said issuers should use the same 
  verification method then if that issuer endpoint has like you 
  know uses a revocation list they will use the.
Manu Sporny:   Exact same.
Manu Sporny:  Verification method in crypto sweet design both the 
  PC and the revocation list.
Patrick_(IDLab): Oh yeah yeah I think so.
Manu Sporny:  Do we have consensus on this language does anyone 
  on the call disagree with this language.
Joe Andrieu:  Yep there is another opportunity here that may also 
  be with Ori one of the things or he was looking for which is.
Joe Andrieu:  If the verifier is surprised by a different 
  cryptographic sweets.
Joe Andrieu:  That does also seem to be problematic in a 
  different way so right you may have a verifier who's restricted 
  to a certain number of Curves right a specific set of crypto 
  sweets and so would be weird if the crypto sweet berries.
Joe Andrieu:  It's a little.
Joe Andrieu:  Different than the verification method varies right 
  you could have different verification methods but in this same 
  crypto sweet so you could rotate keys but don't switch from you 
  know SEC P 2E D 255 19 so different best practices I think.
Manu Sporny:  M so expecting a specific group too sweet to be 
  used for VCS it might be surprising if the revocation list uses a 
  different crypto sweet we say it should use the same verification 
  methods and crypto sweets.
Manu Sporny:  That address the thing you were concerned about.
Joe Andrieu:  Yeah I think that expands a bit too little bit more 
  the footprint Orie was getting it.
Manu Sporny:  Hey does anyone disagree with that addition.
Patrick_(IDLab): If match is my proof of concept I did so when 
  hyper literary so basically you once you have your agent running 
  you can set up a new wallet local wallet and then you choose your 
  did method you can choose either did sub or did key and there's 
  two crypto seats available if you create a wallet with the key 
  method you have.
Patrick_(IDLab):  have the BBS.
Patrick_(IDLab): Us BBS PLS signature 2020 or ed2 5519 signature 
  2018 and then you will be restricted to that crypto sweet when 
  you use that specific did key method.
Manu Sporny:  Yep that's right.
Manu Sporny:  Makes sense to me.
Manu Sporny:  Okay alright so let's go ahead and say that's where 
  we got to this one is ready for PR think it's blocked because.
Manu Sporny:  Of a lack of get apis and I'll leave that there.
Manu Sporny:  Go ahead Patrick.
Patrick_(IDLab): Might be is sort of related but there was 
  another attribute I'm not too sure exactly what it what comes 
  into play It's the proof purpose which is default to assertion 
  method where does that fit in this sort of interactions.
Joe Andrieu:  Should I be in here.
Manu Sporny:  We'll all be seized use assertion method so for us 
  I don't think it means anything VPS use can use authentication 
  instead of assertion method assertion method is used for making 
  statements about the world whereas authentication is used to do 
  like login flows so that kind of stuff.
Manu Sporny:   That makes sense.
Manu Sporny:  With that we've only got two minutes to spare so 
  not enough time to get into this internal versus external API 
  language and we didn't get to 141 so we'll try to get to that 
  next time we'll go ahead and meet again at this time next week 
  unfortunately we've had a drop-in people attending with the new 
  meeting time which was not supposed to.
Manu Sporny:   Happen so I will try and.
Manu Sporny:  Anyone that said that they could meet at this time 
  and see why they're not showing up to the calls the worst part is 
  that we lost I think three implementers by switching the time 
  which is not what we not the intent we want to order that's not 
  what we wanted to happen so we'll check with people make sure 
  that the new times you know there's still okay for them and 
  changing back is going to be probably even more disastrous.
Manu Sporny:   If we do that in we'll try.
Manu Sporny:  See if we can get some of the people that were 
  showing up the last call showing up to this call given the time 
  difference okay any last minute items before we go.
Manu Sporny:  Okay with that thanks everyone for the great call 
  today and we will see you again here next week take care bye.

Received on Tuesday, 4 October 2022 20:25:21 UTC