The State of Anonymous Credentials (discussion)
Session Topic: Attribute-Based-Credentials
Notes-taker: Hugh Pyle
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Lots more attendees to this session than expected for an esoteric crypto topic. So we started with a round of intros & asking why people are interested in the topic.
Andrew (convener): math background & voting systems. Previously: AskForIt startup. Interest areas including proving something while anonymous.
Greg - One use case is to have lots of "demo" accounts, or personas; interested in controls & management to how things become linked together.
Mads – WAYF, Denmark. Have deployed a hub & spoke attribute-federation system, but WAYF actively don't want to know everything about the users; would like to be able to deliver similar functionality, filter attributes for disclosure to various RPs, & mechanisms for users to grant usage-consent without disclosing the PII values to the hub.
Steve - VMware, access management. Balance marketing desire for tracking/login. Access control & authentication credentials
Morten - Alexandra Institute. Security & identity management work. 25years ago was young crypto nerd -> then book about anonymous credentials (Stefan Brands, etc). Thought maybe we would have a truly private internet by now, but still waiting!
Jin - McKesson - has some understanding of uProve. Use case for patient accessing healthcare, with limited disclosure as needed for service provision
Terry - interest in this stuff.
Kazue - NEC - cryptographer. Worked on group signature schemes & anonymous authentication. Has worked through approaches of: standardization, documents. Also working with ABC4trust.
Berit - Alexandra Institute. Background in math, cryptography, but not practitioner for some years. Interested in the gap between research & commercial applications,
Jim - independent - involved in the ID ecosystem steering group.
Paul - NIST - part of NSTIC program office. Business sponsor of Identity Broker. Citizen access to federal applications. Should eliminate trackability etc but don't think it does today. Want to move to something production-ready & commercially available.
William - Google identity team; Some identifiers for purposes of login mainly.
Steve - interested in pseudonymous-by-default
Mary - Google same team as William. Main applications are in federation protocols.
Reiner - independent consulting. Interested in alternatives to anonymous credentials; did a survey for kantara. How can we achieve same goals? - the Canadian late-binding model; or a mirror-like model to anon credentials, = anonymous service providers or relying parties
One problem is how to get these things started. For example, how to build into SAML.
Hugh - Qredo - software startup, building a new platform for applications of personal data; interested in use cases for rapid consumer adoption. Some seem to be around single or few attributes in retail environment.
Bill - New Zealand - ministry of education; worked with government central identity management
Q: uProve: active, alive, working?
- birg should be running beginning next year
- mixed signs from MSFT
- discontinued Java implementation? Nothing happening for long periods?
- decent license though, Microsoft explicitly permissive.
idemix (IBM's identity mixer):...?
- weird license, should be cautious as a commercial enterprise
uprove issuing certs every time
idemix re-using, so more efficient in real uses.
upro? mybe, if want to release multiple attributes -> slow
- talked to ronne bjernst (sp?) from Microsoft
- ZKP versus group signature protocols
Q: are they doing ZKP really?
Andrew: math for idemix is.
Uprove uses *blind* signatures (Brands). If want to bind multiple
attributes they may become complicated.
ABC4trust (EU projects) use idemix?
First thing ABC4trust has a harmonized (pluggable) API for multiple systems with uProve and idemix as two.
Some politics maybe for IP issues
Sweden project - Soderhamn - smartcard with identity - education setting
- prove that you had been in classes -> track when gave feedback
- secure for purpose (no false voting) but retaining privacy
Also there’s a similar project in Greece
Both proof of concept projects
Additionally there is an ISO standardization effort -> quite early, working on a study period
Head is from IBM Zurich
Will probably take 3-4 years before standards can be ready
Other? Different cryptosystems, other implementations??
Group sig libraries? ->
- hard to find a library that implements these things
- MIRACL? & few others with primitives, not end-to-end
Reiner has proposed blinding of the IDP
Q (NIST): re idemix, is it using SAML or ...?
- A: Some addendum, quite vague
- Q: Next step -> profiling so can be deployed in identity systems that support these standards
- Existing standards assume traditional PKI
- Broker model
Morten: Looking for blindable single-use certificates
- for use cases that are traditionally solved in other ways
Hugh -> blinded tokens for service access
Reiner - hopeful - layers, that's the way stuff evolves
- e.g. Gateway / add software layer for access to existing infrastructure
- plus need a back-channel
- e.g. need to send user email
- attach a coin to request
Reiner -> need a pseudonymous recipient address
anonymous/pseudonymous with respect to which parts of the transaction?
Mostly we say that with respect to relying parties
but there are lots of others - IDPs, attribute-providers, etc.
e.g. over21, usually need other information than that
intermediaries are an efficient way of solving the problem
probably want an intermediary in order to provide blinding of who is using these attributes from the authoritative source of them
morten: thing is to do the blinding yourself.
then any intermediary doesn't have the tracking of usage and so on.
Jim: more about being able to abstract some of the information
Hugh -> use scenarios? e.g. age plus photo, where photo is the "recognizer" for F2F
Morten: ZKP attributes - meaning, provable attributes, with the RP unable to pass those attributes to a third party
But: for example, liquor purchase, want to be able to prove to authorities that the user was verified
Reiner: Systems build this as a role for discloser ("designated opener"), able to unlock under special circumstances
Morten: The opener - interesting but some potential for misuse depending on your scenarios
Kazue: everyone has different needs
- but the crypto is different based on everyone's needs
- that's part of the problem comparing with e.g. SAML
Andrew: does that need advances in the cryptography? for standardization?
Kazue: where's the instance to implement?
Nist: working on at least three use cases
- one will be made public once solve it
- (that won't happen immediately though...)
- one will be made public once solve it
- hub approach --> identity & attribute - implementing parts of this
- another: with msft & uprove, some work
- another: recently awarded, hub model, trying to keep subject privacy
So there are at least three attribute hubs? demonstrates a real demand for these things
- USA / nist described
- Denmark - part of ProAc - researching options
- UK - IDESG / Cabinet Office digital services - private-sector IDPs, local & central gov RPs
at varying states of development
shows that use cases are valuable
- single credential to use services from multiple US-government RPs
- attributes shared with consent
- multiple IDPs incl private sector
- good at blinding the identity, but nothing yet in place for the attributes
- Signed & encrypted from IDP to hub -> strips -> repackages for the RP
- Want to maintain that level of blinding for all the PII attributes
Reiner: alternative is to have end-to-end from IDP to provider
- as long as the IDP has no knowledge who they're encrypting for
- attributes passed through because encrypted
UK: assertions are signed across the hub
- so the hub can't change - but can see the attributes as they pass the hub
Morten: Canadian system had a similar
- late-binding model
- blinded token
- Reiner: paper see link: https:arxiv.org/abs/1401.4726
nice thing about end-to-end is that in the SAML world that's minimally invasive
Q: (Reiner) if don't use smartcards as the credentials, what can you use? ubikey? mini-HSM -
- nice, not really "anonymous" in the sense of unlinkable show;
- device holds a secret key; generates keypair, encrypts the private key & sends to RP
- So quite simple, and unlinked across RPs