[MINUTES] W3C CCG Credentials CG Call - 2023-03-02

Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:


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


W3C CCG Weekly Teleconference Transcript for 2023-03-02

  Mike Prorock, Kimberly Linson, Harrison Tang
  Our Robot Overlords
  Mike Prorock, Greg Bernstein, Ryan G, Les Chasen, Harrison Tang, 
  Ken Ebert, Nis Jespersen , Joe Andrieu, David Waite, David 
  Temoshok, Manu Sporny, Kerri Lemoie, kristina, ToddSnyderGS1, Tim 
  Bouma, Markus Sabadello, Wendy Seltzer, Anil John, Clare Nelson, 
  Kimberly Linson, David I. Lehn, Rita Torkzadeh, Lucy Yang, 
  econnel, Priam Varin, Dan Bachenheimer, Bree, Sandy Aggarwal, 
  stephan baur, Frederic de Vaulx, Juliana Cafik, Line Kofoed, 
  Limari (DIF), Stephen Curran, Andres Uribe, TallTed // Ted 
  Thibodeau (he/him) (OpenLinkSw.com), Drummond Reed

<kerri_lemoie> Hello!
Our Robot Overlords are scribing.
Mike Prorock:  Awesome hello all and welcome this is a special 
  topic called with the Mist folks on a wonderful draft which is sp 
  860 3-4 which has to do with digital identity guidelines 
  something which many of us here in this community work on just a 
  little bit so we really appreciate them coming in today to kind 
  of intro the work answer questions help provide clarity.
Mike Prorock:  The call-out in the draft around making sure that 
  hopefully there are some upcoming things like verifiable 
  credentials for instance can be covered by some of this stuff 
  just a quick reminder that this meeting as with all ccg and w3c 
  meetings is covered by the code of ethics and professional 
  conduct I don't think we'll have any issues there but just have 
  to put that reminder out and this is a you know public.
Mike Prorock:   Meeting we're not discussing work items here but 
  if we.
Mike Prorock:  If someone wants to contribute into a ccg work 
  item of any kind you do need to join if there's anyone like that 
  that needs that information don't hesitate to ask in the chat or 
  email directly or email the list and we can get you joining 
  information with that just being sensitive to time I am going to 
  invite the nest folks to kick it off and maybe give a good 10 10 
  minute or so overview particularly of the.
Mike Prorock:   The not just the draft itself but maybe some.
Mike Prorock:  They think there's overlap with this community and 
  then I've got a couple of questions just that the chairs and I 
  the other cultures and myself worked out ahead of time just in 
  review at the Docks and then we'll just monitor the Q the normal 
  fashion so if you're unfamiliar with this group or new to this 
  group if you hit the raise hand button it will add you to the 
  queue otherwise you can just in the chat type the letter Q 
  followed by plus and it will add you to the Q&A.
Mike Prorock:   I will Accu and call them when it is your time 
Mike Prorock:  That missed take it away.
Mike Prorock: 
Ryan_G: Absolutely thank you very much for inviting us today and 
  for giving us an opportunity to have a conversation with you I am 
  I'm going to make a very bold assumption that most of you all are 
  familiar with nist is and what our role is within the identity 
  space kind of sort of within the title of our organization but 
  primarily building standards and guidance 863 revision for is our 
  most current draft of our digital identity guidelines.
Ryan_G: Years there's been several revisions in the past 
  revision3 being probably one of the more notable changes in the 
  kind of scope and structure of how the digital identity 
  guidelines were functioning it expanded what had previously been 
  in revision to kind of a more monolithic document into what 
  addressed different aspects of identity in different ways so it's 
  split what was kind of a gigantic document you for documents all 
  of which are also kind of gigantic in their own right at this 
  point in time.
Ryan_G:  but really it provides a set of.
Ryan_G: Address your base identity model and risk management 
  you're in our base volume 863 a covers the identity proofing 
  enrollment process so how do you kind of validate and verify 
  identity information in order to establish an accountant and 
  Grant an individual credential for authentication the 
  authentication volume which is B which covers multi-factor 
  authentication use of different kinds of credentials and 
  establishes our authentication surance levels and then 863 see 
  which covers are.
Ryan_G: Quirements in Federation Insurance levels across the 
  board so we are attempting with the guidance to cover the full 
  lifecycle of an identity up until the point where you start 
  having authorization conversations which Falls a little bit 
  outside the scope some of the main things we're looking to do in 
  this particular Vision so we had gone through and done a pretty 
  decent amount of Engagement and discussions and release day a 
  call for comments in 2020 prior to the pandemic and so we had.
Ryan_G:  started the process of updating this and evolving this 
  to the next step.
Ryan_G: Started however as with many of these other the other 
  things that the digital world experienced when the pandemic hit 
  you know they were obviously there's always a lot of attention 
  that got turned to online benefits online programs and Rapid 
  transition to from physical and from more Legacy based programs 
  to more digital and online programs and with that the protection 
  of those through identity and digital identity Solutions so we 
  kind of continue.
Ryan_G:  and an.
Ryan_G: Back process to try and gain more feedback from 
  organizations that had shifted into this this realm and make sure 
  that we really captured a lot of the Lessons Learned there so 
  when it came down to it we were really focused on making updates 
  one to start dealing with issues of equity with 63 we did a lot 
  to kind of elevate privacy and usability into the conversation 
  that had previously been kind of the realm of just security with 
  this revision we're attempting to bring I think to a higher 
Ryan_G:  turns around equity and Equitable access to Services 
  primarily as.
Ryan_G: Actions during the pandemic and the reality that a lot of 
  these critical Services need to get to the right people at the 
  right time and identity Solutions and Technologies need to be 
  able to support that we want to make sure that agencies and 
  organizations are evaluating not just the security benefits of a 
  solution but also how implementation of that technology in those 
  Solutions May ultimately impact the ability for an individual to 
  gain access and whether they're inadvertently creating scenarios 
  where entire communities were groups or types of.
Ryan_G:  individuals aren't.
Ryan_G: I will too.
Ryan_G: As well as others it's really dealing with that Equity 
  piece bringing new options to the table and this is actually one 
  of the key reasons were here having conversations today is we 
  really trying to explore how to bring additional identity 
  evidence identity credentials to the table to help individuals 
  better achieve positive outcomes when it comes to interacting 
  with online services and really again this kind of goes 
  hand-in-hand with Equity but also with convenience and security 
  we'd like to be able to do.
Ryan_G:  is provide you know the the larger Community with the 
  ability to make use of.
Ryan_G: Are indifferent and evolving Technologies and options so 
  looking at things such as digital evidence whether through 
  something like mobile driving license or something like a 
  verifiable credential that may be held maintained and protected 
  by the individual but then asserted and able to be trusted by 
  something like the government agency or organization so again 
  that's part of the reason we're here to have these conversations 
  with you all today we're also looking to make sure that we're 
  addressing some of the latest threats that have emerged as in the 
  wake of the pandemic.
Ryan_G:  bviously fishing resistance is something.
Ryan_G: 53 be at this point in our authentication scheme and 
  making sure the providing options that allow organizations and 
  end-users to avoid a very very common pitfalls it's around 
  fishing as an authentication method or fishing authentication 
  methods that are vulnerable to fishing and then also looking at 
  how the identity proofing aspect of things can be compromised 
  through things like social engineering as well as the vast 
  automated enrollment attack.
Ryan_G:  that we saw at the very.
Ryan_G: Making sure that we had controls built in to address some 
  of the things that we saw very commonly as the pandemic rolled 
  out wanted to make sure we address learned and and really take 
  into account the fact that the guidance of this point or five 
  years old identity models identity technology it then only 
  solutions are evolving but also we're learning about the things 
  that you know where the words didn't necessarily equal the 
  outcomes were intending when it got transition from from standard 
  to code.
Ryan_G:  and to implementation so making sure we got good 
  feedback from the community there.
Ryan_G: Overall you know I think there's been a substantial 
  number of changes to the guidance in every one of the volumes but 
  just at a high level some of the major changes within revision 
  for the base volume we kind of updated in moved a little bit away 
  from some of the more strict interpretations of how to do risk 
  management around identity that were in the previous version and 
  focused a little bit more about it on a process-oriented approach 
  that allows for a bit more flexibility in tailoring from 
  organizer organizations and agencies.
Ryan_G:  in the selection of their insurance levels and 
  Technologies we have focused.
Ryan_G: Like digital evidence again this is one of the main 
  reasons we're here today is to understand have we gone far enough 
  and what do we still need to do within our guidance to support 
  things like verifiable credentials that meet with trust 
  expectations for the government Community as well as things like 
  mobile driving license and how those can be part of an overall 
  trust scheme for identity proofing and potentially for 
  authentication as well.
Ryan_G: You know we.
Ryan_G: We've taken an updated 163 see pretty substantially so 
  evolving away from some of the traditional Federation Insurance 
  components to be a bit more clear and concise about what we're 
  expecting it each Federation Assurance level and making that they 
  are achievable I think there was a lot of concern over some of 
  the stuff some of the language and requirements that exist around 
  FAL two in particular that made it hard to understand what was 
  the specific threats were attempting to mitigate and how to 
  really Implement an address of controls appropriately so.
Ryan_G:  I mean that's that's kind of the nutshell probably not 
  quite a full minute here but.
Ryan_G: Happy to dive into specific volume immediately.
<mprorock> "Are emerging authentication models and techniques – 
  such as FIDO passkey,
Mike Prorock:  I think that was an excellent intro and really 
  appreciate it and I'm actually going to start because there's a 
  section in the draft like the initial public draft where I think 
  it's on page a right and I'm going to paste the text in the chat 
  just so folks can reference it if they need to but it says are 
  emerging authentication models and techniques such as Fido pesky 
  verifiable credentials and mobile driver's licenses sufficiently 
  addressed accommodated as appropriate by the guidelines and then 
  what are the potentials.
Mike Prorock:  Some risks awesome statement right one thing 
  though that I thought was interesting is just kind of in doing 
  some text mining since I tend to work in the NLP side of the 
  world a lot and have a lot of background there is there's not a 
  single mention of DCs really in 863 right or potential use at 
  least in the initial public draft and the other gap that I 
  thought was really interesting was the lack of a mention of 
  decentralized identifiers and so maybe.
Mike Prorock:   B63 you know bash for could.
Mike Prorock: https://csrc.nist.gov/glossary/term/did
<sandy_aggarwal> Is there a slide deck being shared too?
Mike Prorock: https://csrc.nist.gov/glossary/term/vc
Mike Prorock:  Like I'm just going to put two links into the from 
  the glossary the Mist glossary end of the chap here in Sandy 
  there is no slide deck that's just pure discussion and Q&A you 
  know VC still pulls back to validating cash in the glossary did 
  does link to decentralized identifier does show that there are 
  some sources in the to blockchain assessments and there's no.
Mike Prorock:   Definition given and there's a TR out.
Mike Prorock:  ER that's not 11.1 working its way towards 24 
  verifiable credentials and so maybe this could be an option an 
  opportunity just to kind of improve what do we mean when we say 
  these terms right let's actually point to the specs from the 
  glossary and stuff like that as people are you know kicking into 
  stuff so that was just like an initial thing but it 
  philosophically like really want to appreciate the reach out and 
  to I think the spirit of that statement about like are we 
  covering these things it was.
Mike Prorock:   Great the fact that it's talking though about 
  digital identity and the fact that then there's.
Mike Prorock:  Up to decentralized identifiers right or dents in 
  any way shape or form seemed a little odd to me because that's 
  the identity portion no VCS will oftentimes be linked into that 
  that's more the identity portion and so it just struck me as odd 
  do you have any commentary on that or thoughts and feedback 
  because obviously there's dids that work with the Federated model 
  there's dense that work with like just pure web linkage cetera 
  right as well as kind of full on individual identifiers as well.
<dan_bachenheimer> the SP 800-63-4 suite relies on a CSP 
  enrolling and maintaining Authenticators for every subscriber - 
  this is CENTRALIZED by definition - what am I missing?
Ryan_G: Yeah I don't think I think what I would argue is that we 
  discussed the use of identifiers I don't think that we make a 
  distinction between a centralized versus a decentralized versus 
  any different form or function of identifiers we do mention 
  verifiable credentials in 863 a I don't know that we go so far as 
  to Define it per say but I think that's something that's very 
  reasonable given that the words show up in the document but from 
  an identifier perspective I don't.
Ryan_G:  think we intended to make any kind of a.
Ryan_G: A distinction between the different types of identifiers 
  that may or may not be used within a mop.
Mike Prorock:  Yeah man oh I'm going to hit you first let's just 
  Dive Right In.
Manu Sporny:  Okay hi Ryan and thank you for taking the time to 
  come here and present the work I know many of us have read 863 in 
  a variety of other you know nist documents I'm one of the editors 
  of the verifiable credentials standard as well as the 
  decentralized identifier one in there's a desire in that working 
  group so I'm talking about the World Wide Web Consortium work.
Manu Sporny:   And group that works on verifiable credentials 
  there's a.
Manu Sporny:  To use portions of 860 863 to it's in fields like 
  evidence so we so when we create a verifiable credential we have 
  these fields that we could use a number of 863 kind of terms in 
  like evidence you know what documentation did you provide to 
  generate this credential that's one way of looking at it more 
  recently we have had.
<mprorock> @Dan - i see you on the queue, you'll be up next
Manu Sporny:  Is around basically like identifier proofing or 
  identity proofing you know if someone is presenting this 
  verifiable credential to you you know as a verifier how can you 
  bind this digital credential to the individual if you don't have 
  a cryptographic identifiers for example so there's this real deep 
  desire to reuse 863 and in the same way that you know the 
  document ask the question are we talking about verified.
Manu Sporny:   Will prudential's appropriately here in 1863.
<kristina> tl;dr. verifiable credential data model is general, so 
  it can be usd to create a VC that is used for proofing, for 
  authentication, for authorization, etc.
Manu Sporny:  I will credentials group has the same ask are we 
  talking about 863 in a way that that you intended it to be used 
  right one of the concerns is that the language in in the news 
  publication is can be interpreted fairly broadly and so we think 
  it would be really useful if you are a number of people that are 
  working on this document can help us with some concrete.
Manu Sporny:   Examples of how.
<kristina> whether a certain use-case is a good idea is a 
  separate question, but matter of fact it can be used.
Manu Sporny:  Inch 863 in the verifiable credentials 
  specification so I think the concrete a skier is would it be 
  possible to come and present some of the of to the verifiable 
  credentials group so that we can better integrate it with the 
  work that's happening in that group.
Ryan_G: Yeah absolutely we'd love to come present I think one of 
  the things we want to at least be able to do hopefully in some 
  kind of concrete ways be able to illustrate where all these 
  different emerging standards and profiles and specifications and 
  guidance actually fit together to create a nice consistent 
  picture of how to use identity versus continuing to have a bit of 
  a fractured view of the world when it comes to these things so 
  yeah we'd be more than happy to join.
Mike Prorock:  Yeah you just got volunteered to be able to spot 
  at the moment it's you enjoyed it all.
Ryan_G: As well as you know how we see it potentially fitting 
  into the VC kind of universe as well and I think you and by the 
  way I'm not the only one here from this I just happen to be the 
  only one who's come off of off of the yeah up of the circle Andy 
  I saw you come off mute there so I'm going to throw you under the 
  bus here and see if you have something you want to say.
Andy_Regenscheid_(NIST): Yeah and I think that question and 
  comment I mean I think it brought up a lot of very good points I 
  mean one piece of context is you know we you know we we try to 
  write 863 to cover a broad range of Technologies we're trying to 
  have it be sort of implementation agnostic so the idea that it 
  could be interpreted quite broadly is often often a.
Andy_Regenscheid_(NIST):  feature although I know that.
Andy_Regenscheid_(NIST): You know creates a you know sometimes a 
  lack of clarity on how things fit in but I think you you know you 
  raised some good points about like where things like verifiable 
  credentials can fit in and as we were working on 863 I think we 
  had a lot of similar discussions about the kind of different 
  models and use cases and I think that's ultimately why you you 
  don't see these Seas specifically used throughout the documents 
  because we sort of saw it potentially fitting.
Andy_Regenscheid_(NIST):  in in multiple places for instance I 
  think you made a very good point.
Andy_Regenscheid_(NIST): Chills could be used as say is as 
  digital evidence that's presented during a proofing process so 
  that an applicant could you know provide you know 
  cryptographically secured proof that they have certain attributes 
  a verifiable credential could with through a verifiable 
  presentation could also be effectively used as an authenticator 
  as a cryptographic authenticator and 863 depending on what type 
  of protocol that's used with and I think they're you know in some 
Andy_Regenscheid_(NIST):  cases the presentation of a verifiable 
Andy_Regenscheid_(NIST): An awful lot.
Andy_Regenscheid_(NIST): Like Federation and present Dina you 
  know an assertion and so we thought that you know this was you 
  know depending on the both the use case and the specific 
  implementation things like verifiable credentials could fit in a 
  number of places within 863 and I don't know how well that you 
  know you know if that matches kind of your.
Andy_Regenscheid_(NIST):  oh thinking of.
Andy_Regenscheid_(NIST): Potentially how it could fit in.
<anil_john_[us/dhs/svip]> SP 800-63D
Mike Prorock:  Yeah Maynard you have a clarification there or do 
  we want to let Dan go.
Manu Sporny:  I do I that's that's great I think the the biggest 
  challenge that we've had in attempting to use 863 in the group is 
  you know some of us will say oh well you know we believe that you 
  can use it in this way and we provide kind of like a concrete 
  mechanism like an identity proofing event or you know evidence or 
  something like that and usually the counter-argument is like 
  that's not how 863 supposed to be used right and so it becomes.
Manu Sporny:   Challenging to cite the document and utilize it.
Manu Sporny:  Disagreement on what some of the language may or 
  may not mean in you know I hate the I hate to say we need someone 
  to referee the conversation but having input into you know what 
  was expected you know to come out of the language that's in 863 
  would help us make you some of the statements there that are 
  general which I agree with you it's supposed to be you know 
  that's that's a that's a feature but what we're trying to do is 
  we're trying to make it.
Manu Sporny:   Really Concrete in.
Manu Sporny:  Can group or work around it because as as you know 
  many of us are working with nation states around the world on 
  digital identity you know digital digital permanent resident card 
  additional drivers licenses things of that nature where we are 
  trying to we're trying to use the guidance and 863 and make it 
  concrete but we're we're we're challenged in that we don't have 
  some of the.
Manu Sporny:   The people that wrote it.
Manu Sporny:  To to sanity check what we're doing it so I think 
  the general asked here is that you know would it be possible to 
  pull each of you in from time to time to let us know whether or 
  not we're on the right track or not when we're doing these 
  concrete implementations.
Ryan_G: Yeah I mean I think we'd be happy to advise on the intent 
  of the guidance I think just to make sure that we're clear on 
  where that line would exist is we can't really be running around 
  saying that we have certified or validated or proved anything but 
  I think where there's questions of interpretation where there's 
  questions of what exactly did you mean here number one I think 
  we'd be happy to participate and help help make sure that you all 
  understand what we were trying to do so that you can harmonize 
  and leverage it within your own specifications and standards but 
  also be immensely valuable for us to understand.
Ryan_G:  where you're seeing challenges in the interpretation as 
  well to I mean we're in a comment period we're going to draft. 
  Here so the.
Ryan_G: If there are things that are not.
<rita_torkzadeh> Has 800-63 been used in ways you wouldn’t 
Ryan_G: Clear as we think they are and the applicability and 
  viability of the guidance is not as concise as it could be I 
  think that would be also extremely helpful for us to understand 
  both from like a conversational perspective as well as if you're 
  able to provide us some some written kind of documentation where 
  you see some of those issues it would be extremely valuable for 
  us to know where other parts of the community aren't necessarily 
  clear on what we're trying to get to.
Mike Prorock:  Yeah and I think a lot of that and I know we had 
  some pre conversation around this just in prepping to make sure 
  we got everything out on the table it was the highest priority 
  items is that there's a big gap in terminology across the 
  identity space today and and so when we look at 860 3-4 right 
  it's it's still kind of caring over a lot of the old school 
  terminology from the Enterprise and government side that might 
  have moved on in The Last 5 Years in some ways right there there 
Mike Prorock:   Current models and different language in use so 
  it's I think this is an area.
Mike Prorock:  So it's extremely timely and it and you know in 
  this comment periods of great way to help clarify and refine that 
  stuff Dan I see you on the Queue here.
Dan_Bachenheimer: There it goes yeah thanks yeah thank you for 
  this opportunity let's see oh okay I don't know if we see these 
  cameras as well but happy to yet and I did put it in the chat but 
  it did you know when we talk about verifiable credentials and 
  things like that we typically yes they can be used kind of stand 
  alone but we typically think of it in a decentralized identity 
  sort of fashion but.
Dan_Bachenheimer:  unless I didn't read it.
Dan_Bachenheimer: The sweet correctly after going through the few 
  times everything in it is centralized to the point where if you 
  know quote throughout the digital identity lifecycle csps shall 
  maintain a record of all authenticators that are or have been 
  associated with each subscriber account to me there's yeah no 
  room for decentralization at all I do appreciate the inclusion 
Dan_Bachenheimer:  switching topics somewhat.
Dan_Bachenheimer: Metric things in there but only one to one 
  biometric comparison is mentioned nothing about one too many and 
  we use the term identity proofing which you say the you know 
  includes in the first bullet is identity resolution determining 
  that the claimed identity corresponds to a single unique avenge 
  individual within the context of the.
Dan_Bachenheimer: This way to do that is through Biometrics 
  that's not even mentioned identity proofing seems to be in my 
  read of this sweet identity verification there's no mention that 
  I've read of how do we resolve an identity to a single unique 
  identity within the context of the population everything that I 
  read relies on somebody else doing that.
Dan_Bachenheimer:  are you talk about.
Dan_Bachenheimer: Using a passport or driver's license or social 
  security number anyhow I've documented dozens of questions in 
  things but those are the two that kind of bubble up to the 
<kristina> the first step should probably be make sure the latest 
  NIST document does not preclude issuer-holder-verifier model, 
  credential format/data model conversation can only come after 
  that. at least in my opinion
Mike Prorock: +1 Kristina
Ryan_G: So I think that's so I'm going to attempt to parse 
  through this and and I'll let you jump in as well to I think 
  Connie and David around as well so you'll have feedback as soon 
  ever won one of the things were attempting to do with this 
  documentation is yes we allow for Biometrics but also we want to 
  account for the fact that there's a lot of folks that are very 
  uncomfortable with Biometrics very uncomfortable with 
  Technologies like face recognition and also acknowledging that 
  there's not really standard common.
Ryan_G:  you know repositories that could be gone to in many 
  cases to be able to.
Ryan_G: Is a biometric.
Ryan_G: He for resolution resolution when you have a large 
  population to deal with like the entire us government's 
  population to deal with so what we look at at the starting point 
  is primarily resolution through the use of attributes and unique 
  attributes that can resolve not necessarily to unique individual 
  cross the entire planet but potentially even within just a subset 
  of Records or things to deal with so that's kind of what we're 
  talking about resolution there's certainly the possibility to use 
  Biometrics for that however.
<dan_bachenheimer> government => PIV requires biometric 
Ryan_G: Scope of what federal agencies do need to deal with it's 
  not necessarily the easiest thing to turn to right away 
  particularly when we're talking about the challenges around 
  biometric performance for one too many type use cases so so again 
  we're looking to try and allow for a broad range in spectrum of 
  potential Technologies to be applied and that includes Biometrics 
  where appropriate and with the right controls but also making use 
  of things like data validation and data matching where we can.
Ryan_G:  for the moment on the centralized versus decentralized.
Ryan_G: I think it's a very fair.
Ryan_G: Comment that the current context and discussion that 
  exists around the the content is that it is very kind of heavy in 
  the traditional CSP centralization Focus I think there's ways 
  that you could look at it to imply that you know if you look more 
  at functionality rather than purely the kind of traditional view 
  of a CSP you can make an argument that a CSP could be something 
  that doesn't necessarily have to be run by an entity and 
  organization but it certainly is heavily implied so we'd be very.
Ryan_G:  interested in feedback directly on how to make sure that 
  our model.
Ryan_G: Of additional deployment modes Beyond kind of the 
  traditional agency runs a CSP CSP operates on behalf of an agency 
  or an organization as well as you know how something like 
  individually on credentials again assuming that there are ways to 
  place rules and expectations around those verifiable credentials 
  or whatever that individuals using to represent themselves so 
  we'd be interested in direct feedback on how to potentially fit 
  that into the model.
Ryan_G:  Andy Connie David any additional.
Ryan_G: Anybody have any advice on how to get these pop-ups from 
  chatting to stuff lying around.
Connie_LaSalle_(NIST): I know I have to look away from the 
Ryan_G: Then hopefully that was that was helpful not sure if 
  anyone else from the team does one away in there.
Mike Prorock:  Yeah I think definitely helped light you know the 
  CSP thinking of the CSP is non-traditional ways that was not 
  clear to me from the text so that's like an immediate feedback 
  area right that area and maybe 80 I saw you come off mic might 
  have some thoughts on that.
<tallted_//_ted_thibodeau_(he/him)_(openlinksw.com)> ryif you 
  "open chat", you'll have a column on the side of the jitsi window 
  ... and the pop ups will stop
Andy_Regenscheid_(NIST): Yeah and I do think that it's it's a 
  fair reading to look at what we have today and say it certainly 
  expects a you know I think you know the csb particularly in 
  improving process to be going through a full resolution process 
  it really only kind of an explicitly envisions the case of a 
  essentially use of a that the user is using a single CSP but I.
Andy_Regenscheid_(NIST):  think Ryan's right.
<tallted_//_ted_thibodeau_(he/him)_(openlinksw.com)> ryan -- ^^^
Andy_Regenscheid_(NIST): I mean I think there's room in the model 
  for say you know any entity that might be issuing say a 
  verifiable credential can be considered a sort of CSP and you 
  know likely we may have to make some adjustments to the model to 
  be able to accommodate that and make us a be really you know 
  interested as you're reading through the documents where you 
  think there is a need for those kinds of adjustments.
Connie_LaSalle_(NIST): Can y'all hear me now.
Mike Prorock:  Yeah and I'm yeah I was going to say just a quick 
  note you know it was typed in the chat but if you actually click 
  the little chat icon on the toolbar and open the chat dialogue 
  it'll open up on the left hand side and then pop-ups will go away 
  because they can be aggravating with the transcriber so and yes 
  Connie we can hear you now so sorry yep.
Connie_LaSalle_(NIST): Oh okay okay I was just talking to myself 
  there for a couple of seconds it's fine I like my own company but 
  I think I think both Ryan and Andy have have covered it I mean 
  one of the challenges of the 800 series special Publications from 
  this is that they're there for feds based on the policy 
  requirements in the federal space required so.
Connie_LaSalle_(NIST):  part of the.
Connie_LaSalle_(NIST): We look to is one we want to be flexible 
  and inclusive but we also recognize that despite our guidelines 
  being voluntary and other contexts they are required so what does 
  the market look like can feds Implement what's what we're guiding 
  them towards so you know we try to be aspirational and 
  forward-looking but we also know that when you are an entitlement 
  program whose dream it is the entire United States.
Connie_LaSalle_(NIST):  like potentially.
Connie_LaSalle_(NIST): Context than the flexibility that a 
  smaller entity might be able to have in making decisions so I 
  just said that context because I think it's important and it can 
  get lost in these conversations that tend toward the art of the 
  possible and the theoretical but just know that that's you know 
  that's a reality that we live in every day and I think we can 
  only update the guidance with your help so I'll just Echo what 
  Ryan and Andy have already said which is if you have ideas about 
  how to make the.
Connie_LaSalle_(NIST):  text more reflective of the.
Connie_LaSalle_(NIST): You're trying to do that's that is one of 
  our goals so I just thank you for looking at it and considering 
  some specific inline updates for us.
Mike Prorock:  Awesome yeah I think there's two folks on the Q I 
  did want to call out a comment and/or question from the queue 
  from Christina who I know is one of the chairs over at the VC 
  working group one of the things in this this I think also jumped 
  out at me and some others I talked to in advance of this meeting 
  is that there's not a clear mapping to the notion of like issue 
  or holder verifier type roles in this and when we are thinking 
  about these.
Mike Prorock:   Large organizational things and I'm sure some 
  folks may or may not.
Manu Sporny: +1 To MikeP -- yes, showing alternate deployment 
  architectures, such as the VC 3-party model, would be helpful.
Mike Prorock:  Like there are some really big rollout going right 
  and and test going including with you know God of so if we can 
  find a way that this text allows us to discuss those roles and 
  how they map that's a very helpful starting place to then talk 
  about how these integrate right and that's something that's just 
  not really present and in that three-party model I think there 
  are ways you could very broadly.
Mike Prorock:   We interpret it that way but it's.
Mike Prorock:  Have to go really.
<kristina> maybe a third table is needed in addition to current 
  table 1 and 2 :)
Mike Prorock:  But which then gets highly highly problematic 
  right when stepping through and trying to say well yeah but I'm 
  using this but that's not really what the text says etcetera 
  right and yeah Christina just noted maybe a third table is needed 
  in addition to table 1 and 2 and you know or an independent right 
  that says look here's Part D or E right that says this is how you 
  know feces or the VC model Maps over right in the first here for 
  evidence and Cetera.
Ryan_G: Yeah I think that's really valuable feedback and and and 
  I actually I don't remember where I saw it excuse me but I have 
  seen someone who did this mapping.
Ryan_G: It was a couple years ago I need to remember where it was 
  and go annoy whoever it was that did it but I think that's really 
  valuable and helpful and I think from our perspective it will 
  also probably help us as well to as we start to think about where 
  we might have some inadvertent gaps or challenges to how this can 
  be interpreted I mean we I was having a call with some folks on 
  the mdl side not too long ago we were kind of joking about how we 
  needed to just create like a glossary that translates 60.
Ryan_G:  322 mdl to verifiable credentials.
<kristina> i mean even terminology in 18013-5 and vc-data-model 
  is not harmonized exactly :)
<kristina> but we are getting there
<mprorock> :)
Ryan_G: What language were speaking and make sure we're speaking 
  the sand and other International standards like you know the some 
  of the stuff around to 91 15 and 29 2003 coming at I so there 
  aren't quite the same as what we say I mean There Are we almost 
  need like kind of a translator for all the various different 
  forms and functions of identity conversations going on but I 
  think from a mapping perspective that's probably a good place for 
  us to at least start as an exercise and hopefully to to kind of 
  support what you've got as well too.
Ryan_G:  two yeah exactly and but but I think that's helpful for 
Ryan_G: Those things in provide some understanding from how the 
  models fit or don't fit and how we might need to make some 
  adjustments or where they would need to be and that is very 
  helpful recommendation.
Mike Prorock:  Yes Stephen I see you on the Q There.
Stephan_baur: Yeah thanks and thanks for the opening you have 
  this call I think there is perhaps and unintended consequences 
  out of the fact basically only have two models and one instead of 
  a silo or the other one instead of Federated identity and the 
  unintended consequence is that of that idps will know where 
  people log in and I'm I'm here from the US Healthcare perspective 
  and while it might not be a problem that idps and over people are 
  logging as far as which agency.
Stephan_baur:  you know their.
Stephan_baur: In the health care of course as polarized as the 
  opinions are it does matter right like then the witch which 
  Specialty Clinic you see and you have interactions with is 
  actually almost you know health information right and so what I 
  mean you want to just see if I can get some initial kind of you 
  know responses from you is on the fact that maybe needs a third 
  model that's maybe not calling decentralized identifier but 
  decentralized identity as opposed to Federated identity.
Stephan_baur:  and important part There is almost like in the 
  model instead of grouping the.
Stephan_baur: To the Sea.
Stephan_baur: SP in our world if we group The verifier to the RP 
  and that the cfpb ew it's then I'll do one thing that of being an 
  issuer of a verifiable credential right so my point is at the 
  moment where the identifier becomes the authenticator 
  cryptographic authenticator the model just significantly shift 
  and I think we have a very important aspect as I mentioned before 
  our privacy that that really needs to be mapped into the model 
  even though it may not apply for the agencies.
Ryan_G: Yeah I mean I think that's reasonable feedback I would 
  say that some of this will help as we start to go through and 
  evaluate I would also note that for example the way you can 
  deploy and do the functions of a CSP as a federal agency or as an 
  individual organization doesn't necessarily mandate that you 
  would always track beyond your agency but I think it's a very 
  fair point that the csps would most likely know where individuals 
  are going so I think it's reasonable to make that.
Ryan_G:  suggestion I also think from just kind of a general 
  perspective we don't really.
Ryan_G: Break apart the CSP capabilities within the model as it 
  says it's depicted so things like providing attributes and stuff 
  like that or verifiable credentials and easily recognizable and I 
  think it's again fair fair criticism and very open to 
  recommendations on how to adjust for that I think Andy just came 
  off me too.
Andy_Regenscheid_(NIST): Yeah and I mean truth be told we've been 
  talking about something kind of similar to this quite a bit 
  actually recently around you know like the model of federation 
  that we cover in 863 see is you know it's it's limited to the 
  scope of you know Federated identity in the sense of you know 
  passing assertions from you know from an IDP it doesn't cover 
  perhaps the you know broader.
<mprorock> there is kindof an implied phone home to verifiers / 
  csps in the doc the way it is written now, especially in regards 
  to revocation checks - definitely something i would love more 
  details on at some point
Andy_Regenscheid_(NIST): You know how you might trust you know 
  inter-organizational trust that would also come up and context 
  like pki so I think this idea you know whether you want to say 
  that it's you know breaking apart the the functions of the of the 
  csb is Ryan was saying or you know attaching identity attributes 
  to authenticators like there is that model that I do understand 
  doesn't really quite.
Andy_Regenscheid_(NIST):  fit into a single place and.
Andy_Regenscheid_(NIST): Sure of 863 and I you know speaking for 
  myself I guess I'm not really sure where you know if we wanted to 
  cover that explicitly where it would best fed you know is to what 
  extent is this is this authentication is this some broader notion 
  of federation or is it as you think we're perhaps suggesting as 
  it kind of a third you know a third model that could be addressed 
Stephan_baur: Yeah that's great I mean again the subtlety is that 
  the identifier becomes the authenticator right so the 
  authentication flows this gives us a change to do the 
  authentication flows without having the need for the IDP right so 
  it can be calm don't come back to be directly down with sort of 
  like still having the benefit of the verified attributes be 
  communicated through VCS right so yeah I will.
Stephan_baur:  thinking about sort of.
Stephan_baur: Meaning you know.
Stephan_baur: That model would look like and how these flows 
  would look like but maybe this community here might actually you 
  know be willing as well to kind of maybe think about it more as a 
  third model rather than just you know individual components like 
  verifiable credentials and I and decentralized identify yours 
  right it's just again I think it's the top indication flow that's 
  the biggest privacy concern.
Mike Prorock:  Yeah that was definitely awesome in it and we 
  could Circle back after we process the key around some of the 
  implied like you know privacy implications and things like that 
  that VCS I think explicitly might have some answers for that the 
  traditional model doesn't Dan I see you on the queue.
Dan_Bachenheimer: Yeah thanks yeah and then yeah that's exactly 
  what was the point I was trying to make it in the beginning if 
  you know where the csps maintain the authenticators and they have 
  to be yeah the relying parties always have to go back to the csb 
  well then there's that is definitely not privacy enhancing but I 
  raised my hand again because you know when Connie was talking 
  about you this guidance being you know for federal for entities.
Dan_Bachenheimer:  he's and things like that you know.
<mprorock> and CBP, and USCIS
Dan_Bachenheimer: The point here and I hear you talk about 
  talking to drivers letting you know motor vehicle authorities I 
  hope to that you talk with Department of State and this goes back 
  to you know the point you made we don't have foundational 
  identity in the u.s. broadly we don't have a national ID but 
  where you say that the the CSP validates the authenticity 
  accuracy and currency of presented evidence.
Dan_Bachenheimer:  well you know Department of State we.
Dan_Bachenheimer: To this date and a few other countries allow 
  folks to take our own photographs manipulate them maybe more for 
  them and it's been proven that some people have and send those 
  into Department of State where they cryptographically signed them 
  but how how are they authentic how how is how our folks looking 
  at the authenticity of a passport photo yes they could see that 
  Department of State cryptographically signed it but I'm gonna.
Dan_Bachenheimer:  people ate it.
Dan_Bachenheimer: Accuracy goes to I would say that accuracy goes 
  through quality and we're not really assessing the quality saying 
  so bottom line is if missed 860 3-4 is saying centralized staying 
  as a Bible for government organizations to create digital 
  identity that citizens could use then why is Department of State 
  still allowing us and not listening to miss the biometrics.
Dan_Bachenheimer:  looks at Miss and making them comply to 29.
Dan_Bachenheimer: I've and why are we still allowed to take our 
  own photos and manipulate them and allowing that to be a 
  foundational document similar for driver's license but they at 
  least those are taken live.
Ryan_G: So we can't let me let me put it let me put it this way 
  we write guidance and we write standards the implant 
  implementation of those is not is not unfortunately our 
  responsibility right that is a responsibility of agencies and 
  organizations and particularly when you start getting into the 
  sphere of things like passport policy and mold dryer and driver's 
  license policy those begin to start get into real rulemaking 
  organizations like DHS and stay.
Ryan_G:  Department that have the responsibility to those so we 
  can provide guidance.
Dan_Bachenheimer: Pick me up.
Ryan_G: Indications what agencies do with that is beyond our 
  scope of responsibility so again we continue to provide the best 
  recommendations that we can obviously wrap Biometrics team is 
  deeply involved with a lot of the testing and evaluation of 
  biometric algorithms but at the end of the day there's not much 
  that we can do with what state department decides to do with 
  their passport policy there.
Dan_Bachenheimer: Very fair and I see in dashboard there's a lot 
  on demographic differentials in the risk of getting it right as 
  was said in the in the introduction about Equity but I think 
  unless they really understand the risk associated this in your 
  risk management that and where we talked about yeah the risk of 
  using a passport photo is it really known that that is risky.
Connie_LaSalle_(NIST): It's almost like you joined our risk 
  management webinar just before this this conversation I mean 
  you're preaching to the choir right and I think that's why it's 
  important for us to work together to figure out the right 
  language on 63 and look I know we're scoping the conversation 263 
  but you know it sounds like in general there's a lot of common 
  research and research questions that we have where we could be 
  partnering so I won't.
Connie_LaSalle_(NIST):  I won't volunteer Ryan's time or the rest 
  of the identity.
Connie_LaSalle_(NIST): I think that's off the table if that's 
  something that is helpful and gets us to a point where we're 
  seeing emerging models like the Cs reflected and guidance like 
Mike Prorock:  Yeah it will and speaking as a ccg co-chair like 
  we do have the ability to you know publish you know effectively 
  little notes from like here's community's assessment and working 
  back and forth with so and so we'd be happy to go through and 
  like work on some of that terminology side and like how do we 
  handle like the three you know three-party side because that that 
  feels like such a critical thing that is not eat it it may be 
  possible but it's not clear in the docks and that that's such a 
  fundamental piece I met new.
Mike Prorock:   Quick question I know you're up next on the Queue 
  but I felt like.
Mike Prorock:  Call out to like DHS and the folks setting the 
  policy and seeing someone for BHS on the line would you mind if I 
  called on them to ask some questions there so Anil I'm going to 
  put you on the spot.
<drummond_reed> Nothing like having Anil on the spot! ;-)
Anil John:  Oh thank you Mike I appreciate that good morning good 
  evening good afternoon good night and he'll John technical 
  director Department of Homeland Security hello date tamasheq good 
  to see you again as well so it was interesting to hear obviously 
  very familiar with Nest particularly in my formal role as ficam 
Anil John:   Lead at GSA.
Anil John:  Yes and in this particular context as it regards a 
  verifiable credentials than these are the lies identifiers I am 
  speaking obviously for the needs of couple of my components of 
  DHS in particular US citizenship and immigration services and US 
  Customs and Border Protection that are actively moving out on 
  implementing verifiable credentials and decent lies are in the 
  fires in our operational use right now in within the context of 
Anil John:   He is it is about digitizing currently paid.
Anil John:  But are focused on immigration the permanent resident 
  card employment authorization documents and the like and 
  obviously on the u.s. custom side digitizing cross-border trade 
  documents using the same Technologies so there are agencies 
  within the US federal government to whom this technology is 
  obviously highly relevant to whom 863 absolutely matters a lot 
  and separately as.
Anil John:   Somebody who was involved.
Anil John:  Helping what became 860 3-3 where we actually broke 
  out the monolithic aspect of authenticators and identity proofing 
  entirely separately I think there is a path forward in order to 
  sort of baking what is needed with the decentralized identify 
  ecosystem into 863 as well so I am not going to put - colleagues 
  on the spot spot here and that is not my intention.
Anil John:   But I do.
Anil John:  What is it.
Anil John:  The station that need that we need to have regarding 
  perhaps to use a phrase earlier I represent the interests of a 
  one particular organization that is in the benefits granting 
  business on a population scale on a global scale US citizenship 
  and immigration services that is using this technology and plans 
  to use this technology so we do need to find a way to make sure 
  that the approaches of this technology.
Anil John:   Neurology are indeed something that is sort of.
Anil John:  In the structure of 863 so that we can all you know 
  solute and move forward and actually do right from the security 
  and privacy so the long and short of it guys is that we are I 
  think we are at a stage where we need to have a conversation and 
  I'll be reaching out to you.
Ryan_G: Absolutely look forward to also that's one of the reasons 
  were here right now is we see that this is kind of you know we 
  want to make sure that the guidance is not 5 years behind the day 
  it comes out and so I think making sure that we are taking into 
  account what's emerging what's evolving and being as clear as 
  possible about how to fit different in new emerging models within 
  the context of 63 I think is important going forward.
Anil John:  So I also want to be very clear right I think you 
  know there is a there is a there is a framing that often goes on 
  in this context particularly in a lot of the government circles 
  where this is emerging this is very early this is whatever as the 
  you know agency that actually originally funded some of the work 
  around this 7 to 8 years ago we've been involved in it from that 
  beginning so we.
Anil John:   We consider this to be emerging but we do consider 
  to be.
Anil John:  A long painful process in order to ensure that there 
  is global acceptance with these standards in all the things that 
  we're doing and particularly from the USCIS and CBP side we are 
  also looking at counterparties you know in both of those contexts 
  that are you know moving out on the digital wallet use cases with 
  the European Union's European identity digital wallet we are 
  envisioning use cases where a you know EU member states.
Anil John:   Citizen with the digital.
Anil John:  To the front door of a USCIS and we would like to be 
  in a position where our credentials can be issued into them and 
  they're at the station's about things that are coming in verify 
  the credentials for Max and the light can be acceptable for us so 
  there is a desire to make sure that this is not just fit for 
  purpose for government but also on the global global 
  interoperability side of you know jurisdictions and solvents 
  talking to each other as well.
<drummond_reed> The European Digital Identity Wallets initiative 
  is a fantastic example of why VCs should be fully recognized by 
  this next edition of 800-63.
Ryan_G: Yeah and apologize for huge emerging but I think we share 
  the same vision there particularly in the ability to establish 
  broad interoperability Global interoperability and making sure 
  that we're staying aligned and connected both internally as well 
  as International.
Mike Prorock:  Awesome cool looking forward to many continued 
  interesting improvements to the spec man who I see you on the cue 
  and you might be the last one up depending on how long the 
  answers are to your question so.
Manu Sporny:  Thanks Mike I guess this is in in a similar vein 
  there are a number of technologies that the verifiable 
  credentials in decentralized identifiers groups are I don't want 
  to say they're incubating I don't want to say they're emerging 
  but you know these are privacy-preserving Technologies right in 
  we've been trying for a very long time to try and push this work.
Manu Sporny:   Forward so I noticed that you know.
<kristina> why are we shy saying it is "emerging"? it's not like 
  there are billion of verifiable credentials or mDL, ye.
<kristina> *yet. is there potential? absolutely.
Manu Sporny:  3C mentions you know privacy enhancing techniques 
  and I know that it's mentioned several times throughout the 
  document I think it would be helpful to call some of these 
  Technologies out more directly things like selective disclosure 
  things like on linkable digital signatures basically help 
  individuals only expose the information that they need right I 
  mean there.
Manu Sporny:   There are things like General.
Manu Sporny:  Sharon in the EU and I know in the u.s. they're 
  different privacy regimes that are being talked about and one of 
  the challenges that we've had as a group is every time we start 
  talking about selective disclosure or unlikable signatures or 
  things like that almost immediately you know it's like Miss 
  doesn't that's not a proven this crypto it's not even talked 
  about at nist good luck you're going to it's going to take 
  another 10 years to get there which you know kind of feels 
Manu Sporny:   I'm wondering if there has been.
<mprorock> @kristina - i think it is a fine line, definitely 
  rapidly heading towards billions, but more on the health and 
  trade side
Manu Sporny:  Discussion about adding you know potential 
  beneficial future directions into these documents without 
  necessarily blessing them as you know appropriate at this point 
  in time like you know there's given the how long it takes these 
  documents to kind of rev it would be nice to to have language in 
  each the each of these documents that show.
Manu Sporny:   Oh that you know.
Manu Sporny:  Like a pairing friendly curve you know BBS 
  signature on something is of interest from a privacy perspective 
  doing a selective disclosure using you know SD jot or some other 
  mechanism is something that is viewed as a viable a reasonable 
  goal to move towards so that you know effectively we stop having 
  these nice pecs being used as kind of hammers to stop that or.
Manu Sporny:   Work right.
Manu Sporny:  Again I think as you said and as is stated in the 
  document we're all trying to do the right thing and minimize 
  information that's being shared and make sure that people's 
  privacy or being being protected but one of the ways that some of 
  the nist Publications are being used are too you know halt or 
  slow some of that work certainly not by nist by you know other 
  other entities in the in the ecosystem have have you.
Manu Sporny:   Consider door.
Manu Sporny:  Language already exist specifically language that 
  calls out selective disclosure and why it's beneficial to use 
  that in detail or unlink Bill signatures like BBS in why it would 
  be a useful attribute of a system to have that.
Andy_Regenscheid_(NIST): And we're certainly not trying to put a 
  stop or slow down that work at all I mean I am based out of the 
  the cryptographic Technology Group at nist the one that puts out 
  the cryptographic algorithm standards and guidelines I mean we've 
  been very interested in you know a variety of approaches for 
  privacy enhancing cryptography and privacy enhancing Technologies 
  you know so when we you know when mist is engaged in places like 
  ISO on the.
Andy_Regenscheid_(NIST):  you know mdl standard those are things 
  you know features that we're looking for.
Andy_Regenscheid_(NIST): Okay first of all I mean II think it 
  would be good to get your feedback you know it's good to get 
  feedback here but also good to get your feedback during the 
  comment period on you know what could be some of those you know 
  those properties to that could be you know referenced you know we 
  do talk about related properties in the context of say Federation 
  protocols you know but they don't necessarily have a.
Andy_Regenscheid_(NIST):  we don't really.
<mprorock> "Derived Attribute Value" which is defined in the 
  draft is definitely an area where these concepts apply
Andy_Regenscheid_(NIST): A separate place that talks about those 
  things in the context of things closer to verifiable credentials 
  so I think there's a mean I think there's interesting work to go 
  on and I think that's also interesting work for you know 
  basically I think that's interesting feedback both you know also 
  for the you know in this cryptographic technology group as we you 
  know look at where where you know looking to you know Target are 
  you know efforts I mean we.
Andy_Regenscheid_(NIST):  we have a lot of discussions about some 
  of these things I mean we had.
Mike Prorock: +1 Andy
Andy_Regenscheid_(NIST): Active program on privacy Nancy 
  cryptography for you know close to you know 10 years now longer 
  depending on what you count you know I will acknowledge it part 
  of the challenge that we have right now is is that we're very 
  interested in in post Quantum cryptography and some of the 
  techniques that have been historically pointed to like pairings 
  you know would be vulnerable so you know we are also now looking 
  at you know what new lattice base.
Andy_Regenscheid_(NIST):  schemes you know could be.
Andy_Regenscheid_(NIST): You know are out there in order to 
  provide similar properties that would you know resisted X by 
  quantum computers anyways I think you brought up a lot of very 
  interesting points I mean I think those are things that we'll 
  have to connect it to dig into more.
Ryan_G: And I think some of this might also have some opportunity 
  to be a bit more precise and in translatable and some of the 
  language I mean we we've got data minimization is a very 
  important concept to us and selective disclosure is a way to 
  achieve that more directly we've got Concepts like I think we 
  call derived attribute values but essentially not providing all 
  of the attributes so much as providing just kind of you know 
  critical responses but I think in particular be very valuable to 
  get that.
Ryan_G:  very specific feedback and the other thing I will add is 
  we do work pretty closely with our privacy engineering team.
Ryan_G: Well to who works.
Ryan_G: On privacy enhancing technology not just crypto based off 
  but you know other IAI machine learning and kind of privacy 
  enhancing models so I do think the if there are areas where you 
  can point out very specific hey you know you talk about this 
  concept that's kind of sort of like the concept that we have over 
  here being more concise and being more specific about how this 
  would look and what it might look like would be helpful to us as 
  we as we start to again I think account for the broader range of.
Ryan_G: Entity and credential models that are starting to emerge 
Mike Prorock:  Yeah and then and I think that's a great note to 
  get you know kind of clothes on as far as like a lot of this is 
  terminology some of it is there is a gap right the role cons like 
  this three-party role section is not really covered or explicitly 
  allowed and they mean there's good call-outs and do a TC and 
  things like that and the in the draft but not really back in like 
  well how does this map in on the PC side that's very I think we 
  can help but the that notion of derived.
Mike Prorock:   You know I think I called out the exact size.
Mike Prorock:  Mentioned it right that derived attribute values 
  right that's a one-to-one effectively with this notion of a 
  derived predicate right in in the VC data model and there are a 
  number of items like that that I'm sure as folks are going 
  through and prepping responses hopefully they will call out 
  because those are the things that are very actionable and they 
  just a big plus one on the post Quantum stuff so just as always 
  liked working on some of those things over at ietf.
Mike Prorock:   Find glad glad to know that that is on your mind 
  as well as the.
Mike Prorock:  So with that I know we're about a minute and 40 
  seconds or so over time I'm going to give missed the big thanks 
  really appreciate the time today from everyone if there's any 
  kind of final Last Words thoughts call to action etcetera let's 
  please do it now and then I'll stop the recording and hopefully 
  this is the first of many helpful you know productive pack.
Ryan_G: Yeah and we again we are more than happy to continue to 
  have these conversations I think it's really important and if you 
  would like us to connect on how we can present to some of your 
  other working groups to make sure they understand the intent of 
  63 and Guy fits just let us know and we'll figure out how to get 
  some folks there.
Mike Prorock:  Awesome yeah absolutely and I'm sure I know 
  Christine is one of the editors the VC working group she's on 
  this call Manu myself at a number of items along some other folks 
  on here so I am sure there will be some reach outs drumming 
  diagnose on the Queue and I think he's over at the did you know 
  with more of the did side so I am sure there will be some reach 
  outs for very specific working group and terminology and like how 
  does this apply can we clarify type items so awesome well thank 
  you so much all again.
<drummond_reed> Sorry, I meant to hit the "clap" button ;-)
Mike Prorock:   Really appreciate it really appreciate the great 
  questions and.
Mike Prorock:  Looks and just looking forward to practical 
  actionable stuff and loving loving the fact that hopefully we can 
  get some great comments back in and make the stock better for all 
  of us so thanks again.
<harrison_tang> Thanks, everyon!

Received on Friday, 3 March 2023 01:38:27 UTC