Secure Patterns for Internet CrEdentials (SPICE) BoF 09:30 - 11:30 Tuesday Session I / Congress Hall 3 * [Consolidated slide deck][1] # Welcome and Introduction {#welcome-and-introduction} Chairs: Pamela Dingle and Hannes Tschofenig Note Well # Problem Statement {#problem-statement} Background information ## Market Driver {#market-driver} * Leif: (starting at slide 9) * the focus is only EU market. it is a negotiaiton process between all member states and European Commission. * legislative context: EU's attempt to build *"digital identity wallet"* * Large scale pilots - implementation acts (tech spec masquerading as law) Must be based on standards in ISO or ETSI - they don't have to write the standards can reference standards produced elsewere Initially in person in party flow (drivers licence to police officer) Major driver is web based use-cases (openID for VCI and OpenID for Verifiable Presentation) Two work strands on each of the abor\[...\]? Wouldn't hurt if EU came out of this with global interoperability. Ask to IETF community - would like to have foundational standards ready sooner rather then later. Focus on issues related to credentials' security and privacy and need to be worked out. No time to duplicate other work - happening in other venues (OpenID Foundation for example) * Brent (starting at slide 12): We need information signed and secured. Common flow (Three party model): * HOLDER provides an assertion from an ISSUER about a SUBJECT to a VERIFIER. * the assertion is issued in a CREDENTIAL. * the assertion is provided to the VERIFER * CREDENTIALS and PRESENTATIONS are evaluated according to policies We need better technology that is more secure and more private. Slide with examples of some technologies (along with rough timeline) Automated decision making is the focus. Three party model was well marketed by W3C Work. What we want to do is take these idea and build upon them and make sure they are secure and private as they can be. # Selection of proposed work items {#selection-of-proposed-work-items} ## Identifier / Key Discovery document {#identifier--key-discovery-document} * Kristina (starting at slide 17): Three party model is not what OAuth is chartered to do. User controlling the keys during presentation that they controled during issuance. Not only usage with "natural persons" but also "legal persons" Pros and Cons (slide 19) some use-cases require history of the keys. not .well-known paths for finding keypair there is something in /JWT-issuer No off the shelf interop with DIDs => hesitation from implementors. Identifier and key discovery mech How get keys and how trust is established. ## Technology Driver {#technology-driver} * Orie (starting at slide 23): Also trade information. Securing cyber physical supplychains, and trade. need for concise representations (as data can quickly inflate) Issuer claims about subject. (Holder is not always subject) data presentation needs redaction to only reveal the minimum amount of information necessary to take decision with traditional signature schemes you have to present the entire payload. selective disclosure is a fundamental building block for all this work (balance the needs of business and the needs of individuals) decrease the secruity and privacy issues by working on selective disclosure from the beginning, along with unlinkability. Selective disclosure in COSE instead of JOSE. Binary doesn't have to be text encoding. Important when you have nested structures. Familiarity with JOSE development systems. Then started to use COSE strucutres. Synergy and alignment is a good thing. Selective disclosure structure (SD-CWT) (slide 26) challenges in presenting in JOSE that COSE doesn't have. SBOM (Software bill of Materials) use case: Work within SCITT working group on securing software supply chain. SBOM has been in the news - tells you what went into the software. Tells you all the places that need to be fixed if something is wrong. Example SD-CWD SBOM payload structure uses 222: label twice as the locations where we put the binary representation of the disclouse ## Privacy: Selective Disclosure and Unlinkability {#privacy-selective-disclosure-and-unlinkability} * Mike Jones (starting at slide 29) Asked to talk about Privacy. We could build identity system where people asked for information about you - they got all the information about you. Motivation is to do better then that. privacy = minimise disclosure enablers: [OpenID connect claims request parameters][2], [SD-JWT][3], ISO mobile Driving License (mDL) privacy = not "calling home" can use physical plastic card to buy alcohol and to board an airplane - the card does not contact the issuer. OpenID Connect and SAML do call home. the IDP knows where you ask. VCs don't "call home" Wallet can see where you use them - not the issuer. Privacy = non-correlation amongst verifiers. Work on [BBS][4] going on in CFRG to enable ZKP Prevent correlation between issuers and verifiers. Trackers and what they do with the information. Privacy = Releasing Proofs rather then claim. BBS+ work can do this. # Clarifying Questions {#clarifying-questions} * Manu Fontaine: ? * MCR (question for Leif): the extent to which using smart-phones is important? 1. Person to person adjacent. 2. Expectation that my credentials that are connected to TPM. * Leif: Not just for smart phones. * Roman (question to Orie): I observe in many cases this JSON vs CBOR thing - why you think it's more complicated in JSON? Could we have a single CDDL that produces both JSON and CBOR serialisation of the same info model? * Orie: need to harden JSON Base64 serialization unicode encoding matters. When you create signature with constraints building on of it you encounter Protected header, SD-JWT - JSON, JOSE - append to string with Tilda - JSON serialization in unprotected header. Mirror JOSE and COSE are typically aligned - but some times not. Preserving privacy and security. # Charter & Milestones {#charter--milestones} TL;DR (by IdentityWoman) We are creating a venue for individuals who really want to work on verifiable credential stuff at IETF. Charter discussion started already (see [https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md][5]). Got already some feedback from Roman (thought there's more!) Selective disclosure unlinkability. The charter as currently drafted says: "protocols are out of scope." We hope that protocols will be independent of the data representations. The starting working set is: * informational doc architetural * PS doc for selective disclosure using CWT * PS doc for unlinkability with CWT * PS doc for identity docs with CTW Always go where the experts are. This meeting has 150 attendees! # Discussion {#discussion} Direct presentation is over. * Dmitri Zagidulin: who came up with the SPICE acronym? A: Orie * Say more about extensibility. Extension points to do other thigns * Henk: Digital drivers license. Problem QR codes kind of same thing. Records I've done some bad thing - require expiry of disclosure after a while. International interactivity. Passport analogy - going somewhere presenting. What does immigraion desk - want to enter country without bias. (ideal world) all items could be achieved with subset. * Dmitri Z: How is that extensibility * Henk: extensibility you need more characteristics - algorithems to disclose or undisclose - there are different algorithms in different jurisdictions. * Bob M: dragged kicking and screaming into world of Aviation (ICAO) get to certificate authority for digital passports (PKD) if you are talking about how passports get into this - x509. 10 years and the craft is moving - see how this works with it. To roll roote certificate on aviation fleet is 3 years. * Hannes: soungs like good input into the architecture: separtion of credentials from protocols. they will need to be mixed - interactive selective disclosure. presentation disclosure to survey them. * Kristina: Straight forward answer Building protocols natural persons * Jonathan Hoyland: Had quick read of charter - should work with all these working groups - one left out - PrivacyPass, why? * Brent Z: We forgot. * Manu Fontaine: Good introduction. Focused on privacy very important. Wanted to bring work of confidential computing verifiable software on verifiable hardware - develop software agents cryptographcially bound to entities. You can have agents that talk to one anther do exchange of data that is invisible from humans - encrypted and protected. confidential-computing agents can enable some of the use cases discussed by doing the needed computation in a trusted execution environment that is privacy and confidentiality preserving. assuming such computing environment simplifies the architecture greatly. Intersted in contributing to group. * Hannes: compared to just a few years ago, we now have technology that enables new capabilities that allow us to store credentials more securely. Cedric Fournet: question about scope: the idea of separating credentials from protocol. this seems not really possible in certain flows. Kristina: at the moment there is no clear winner in the credential format space. aim at consuming credentials created in other groups (e.g., SCITT). Shiigeya Suzuki: why discovery is out of scope? Kristina: discovery, key resolution, authentication... Hannes: the "identity documents" will deal with this -- we didn't forget about it. Orie: Privacy pass: As I prepared slides on how IETF - privacy pass was missing. unlinkability as property good pieces in both (Oauth) non-natural person identity machine identity and bot identity and some of what privacypass has been doing is very interesting and we need to include it into the work. Roman (as individual): clear about info/data model building blocks but currently confused by the sections of the proposed charter related to the identity work. in particular, the statement "no protocol work". how is discoverability, which looks like proper protocol work, going to be taken care of? Leif: maybe word "protocol" gets us into trouble - many aspects of protocol do apply. Transport protocols are out of scope - way credential gets from issuer to holder and holder to verifier. Roman: when I read a transport protocol I don't think of that. Hannes: privacypass has many elements to it. Daniel Kahn Gillmor: some transport protocols have linkability problems, thus privacy impacting. It seems odd to keep those out of scope. Discussion in a chat - what to people do who don't have devices. Things deployed at scale for getting around society. Sometimes you run out of batteries. Avaliability - offline paper credential usecases - some of theings we want are not possible with offline or paper use-cases. What to do without a device. Leif: yes, I agree with DKG these are important problems. Kaliya Youg: People are working on cloud based wallets may be a solution to the problem DKG highlights Denis Pinkas: there are predicate proofs that are also possible. you need to support protocols in addition to data structure. Hannes: architecture doc contains vocabulary, roles and conceptual messages flowing between the identified roles. many instantiations are possible. no need to be religious about that. Justin Richer: I got in the queue to raise question about protocols being out of scope. What is the plan for all the things this forum deems out of scope. lots of need to liase with - so work does go to the right place. "says VC" so it goes in spice. We will have to put in the charter. Hannes: we need persons from other SDOs directly in the WG room/ML vs official liasons. it simplifies the information flow a lot. Oliver Terbu: there is a significant overlap between OAuth Experts and SPICE work - conceptual overlap between CWT documents and SD-JWT VC work that was just adopted after IETF 117. Issuer discovery and validation, e.g. using DID, x509 etc. I agree that presentation exchange should not be a priority but don't agree that other protocols should never be in scope. For example, issuer key discovery could be inscope. Hannes: key to have alignment. Nick Doty: CDT there has been some discussion of privacy and it is concerning that we fogot other groups that work on Privacy good to be consider selective disclosure and unlinkability - and concerned only asking about any other privacy properties - transparancy, control, accountability. Do we think we about places this technology is misused and how it will be mitigated. Worried about a "papers please internet" wehre must preset government paperwork. Not just there is an EU law and we better do something. Hannes: Gave Mike 10 min and didn't cover full bredth. Please bring these additional considerations Orie: I work on transparncy services for sofwtare usecases. I find interesting - duality between transparcny and unlinkability - unlinkability with a special kinds of transparancy. Have we thought about all the ways - no. Excited about the convergence of transparency, unlinkability and ZKPs. Having a place to talk about risks to talk about design principles. Shares concern about 'papers please' cautious about world where this was rolled otu everywhere. IETF organs like IAB can address concerns. +1 to your concerns Manu: Think of introducing confidential personal agent verifiable piece of software to what is happening. Issues get resolved. Kristina: Stab at what Justin mentioned that is out of c ISO, IETF, DIF, W3C, OpenID Foundation I have some claim to understanding RDF is out of scope. Has to be defined better focus on 3 party model. Better stab Leif: differentiating transport protocols from credential formats. Data person is attesting about a How the keys to verify that is not always in scope. Transport is more exchanges with query languages - defining a new transport protocol should be out of scope. Refering to them in an architecture document they could be mentioned. Anything that fulfills requirement. Getting this 3-party model right is very hard. Not going to be perfect we have been working on it for 6 years. A lot of it is regulations and requirements from that. If we will wait for the best ZKP algorithms to come to completion and be ready to be deloyed at scale. Balance with what the technology can actually do. Leif: Address nick's concern "papers please internet" I never found that we were getting technologies so simple - overly deployed. What we are building EUDI wallet space. simple show licence to show practice nursing in a different country. To your point Roman the verticals will be represented - university educational credentials, K-12 credentials, labor market, social security are specific usecases in large scale pilots. Roman: is the IETF creating building blocks for other to creating the protocols or is the IETF taking care of the protocols itself? Leif: the former (building blocks) - so it can be globally interoperable and privacy preserving Geovane: interest in compact identity documents for IoT scenarios DKG: push back on the idea that we need to depend on the regulator to make the accountability mechanisms. we have an obligation to provide hooks for accountability, especially for verifiers and issuers. we need to protect the holders who are the weakest in the 3-party model. # BoF Questions {#bof-questions} * Chairs / Area Director (Roman): Hannes: Where do we go from here? The charter text is not yet there (clarifications around protocols, language around privacy, etc.). We need to get the sense of the room now. From RFC 5434: * There is a problem that needs solving, \[...\] Yes: 85 No: 5 No opinion: 66 Participants: 157 (one double vote?!) A clear yes. Some of the "No" wants to provide a reason for their no? Nick Doty: I voted no because I don't understand what is the problem we are trying to solve. * \[...\] and the IETF is the right group to attempt solving it. Yes: 69 No: 4 No opinion: 84 Participants: 158 Mallory Knodel: there is work ongoing in other SDOs (e.g., W3C) I am not comfortable with that. Rifaat: so many "no opinions" because people do not understand exactly what we are trying to solve Hannes: reminder of the scope (CWT based building blocks) * The scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what it won't) and what its actual deliverables will be. Yes: 24 No: 57 No opinion: 74 Hannes: a bit in contraddiction with waht we had initially. This seems like the problem statement is not as crisp as it needs be. Guilin Wang: no familiarity with the voting tool: can the chair remind especially the remote participants how one votes? Hannes: explains quickly how the vote works Carsten Bormann: the problem is huge, and I don't understand the whole scope. the problem is so big then it would be realy weird if I did understand it. David Waltermire: Milestones written in a fairly abstract way didn't do a deep review of charter and more review. Hannes: Responsibility for participants to look through text. For me the milestones for what they want to work on. Unlinkability for JSON work is also avalialbe should give you a good idea where this is headed. Point taken. Manu: I said Yes, Yes, No. There is a problem that can be tackled. Tech has evolved a lot, and there are now computation primitives to do solve some of the underlying problems. # Wrap-up and Conclusion {#wrap-up-and-conclusion} Roman's observations: 1. lots of people in the room (which is fantastic) 2. question about whether there is a distinction between what we have talked here with work already in flight in other WGs (e.g., OAUTH) 3. based on conversation and engagement: there is definitely work to be done and energy to do the work 4. there is currently some amount of mismatch between scope and problem statement: the charter is not a crisp enough description, it needs to be refined. We need to go back to the ML and discuss the charter until the scope is defined well-enough so that we can start doing actual work. [1]: https://datatracker.ietf.org/meeting/118/materials/slides-118-spice-complete-slide-deck-pdf [2]: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter [3]: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ [4]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/ [5]: https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md