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 so. ✪
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: 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: 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 level. ✪
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: 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: 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: 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: 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. ✪
<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 cases. ✪
Andy_Regenscheid_(NIST): cases the presentation of a verifiable credential. ✪
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): 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: 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: 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. ✪
<rita_torkzadeh> Has 800-63 been used in ways you wouldn’t expect/anticipate?
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 are. ✪
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: 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 of. ✪
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: 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 surface. ✪
<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
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: 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 enrollment
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: 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: 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 screen. ✪
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. ✪
<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. ✪
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): 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): 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. ✪
<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. ✪
<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 us. ✪
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: 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: 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 separately. ✪
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: 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: 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. ✪
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 this. ✪
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 technically. ✪
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 use. ✪
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: 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: 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: 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: 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 self-defeating. ✪
<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: 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: 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: 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. ✪
<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. ✪
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: 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 or. ✪
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. ✪