Decentralized Identity, OAuth, OpenID and How They Can Fit Together
OAuth OpenID Decentralized ID
Wednesday 4F
Convener: Justin Richer & Nathan George
Notes-taker(s): Scott Mace
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Looking for patterns and commonalities; looking for terminology mismatches.
A lot of patterns have been solved.
How do get enough nomenclature up on the board.
Justin on OAuth: Started 10-11 years ago when APIs were protected with user names and passwords. How OAuth works, the fundamental assumption. Web site on one side and other side. Wasn’t want the entire world looked like. OAuth2 added things that didn’t exist, such as mobile.
Still assumption OAuth is about protecting some type of API. The interesting thing with Open ID Connect is we will define an API. That API is who is the current user. That’s who you’re protecting. Twitter and Facebook did this exact pattern. A million versions these days. The architectural assumption is there is an API that has all my identity information that I’m trying to give access to.
Nathan: Self-sovereign idea. Trouble is a lot of these services, the only construct that makes the user the user is under their control so you can disintermediate the user entirely. Self-sovereign: Intermediate the data and the user. No one can impersonate this entity. Differs a lot from UMA. Not that user manages access. Point is entity can’t be impersonate. No central CA or root of trust. Use cryptographic key instead.
Q: Core of all truth starts there and not anyplace else.
Justin: An antipattern Open ID Connect set out against. If look at more traditional SSO systems, spit out encrypted domain cookies, SAML and Open ID 2, hand something to user’s browser who hands it to a bunch of different sites. But this whole notion of the user having to carry that artifact with them, when you build this around a Web browser, turns out to have holes and bad problems. Info leaks into browsers and plug ins. Browsers being tricked to send cookies to domains. So one thing Connect did by basing specifically off OAuth was to get user info directly from the API. What user had was generated by a trusted authority. Harkens back to X.509 PKI. You get same thing, your cert, for everyone who asks. Lots of problems with lack of flexibility. The whole API-based Connect model was by and large a community tech response to a lot of the problems with that system, which is why it doesn’t get rid of the notion of the API but moves closer to it.
Nathan: Self-sovereign doubles down on claims being verified by a third party for triangulation. All info can resolve back to something I’m willing to use to grant access to the API info.
Q: These problems bit first-generation bitcoin startups.
Nathan: You’re looking for third party attestations. Look at the CA authority, that is their business model. To bind a key to an attribute in question. By moving model away from RP, info flows more easily, but also making seeking back to the root of trust a multistep process. Hope is you are dealing with the same issuers over and over again so you’re not paying for the expense every time. What’s the plausible deniability of a driver’s license? By automating this, I can ask a driver’s license authority, how are you an authority? The hope is to boil it down to a smaller set of info. To present minimal information to a bouncer. Just like identity is contextual, trust is contextual.
Justin: In order to get scalability, we outsource a lot of that stuff.
Nathan: One of the strangest topics, how do I know what this attestation means. Anyone who has worked with medical data knows people don’t put the right things in the right fields. Trust is who is the issue as well as the schema and how strict that is. Need some sort of chain of custody.
Justin: Do you want market forces controlling your schema?
Nathan: Some sort. It may be glacial.
Justin: It’s the acceptance of trust I would be surprised.
Q: You can have a normally trustworthy source be untrustworthy for a time.
Nathan: Which is why a ledger can be helpful, because of timestamps.
Sam Smith, Xaltry: If you use distributed consensus as part of your trust chain, windows of lack of trust become much smaller. Been motivated by the blockchain.
Debbie Bucci: Like caching?
Nathan: If I can sign a resource, I can distribute it. The way we’re doing claims and proofs doesn’t give us the ability to reshare, but the idea is once you have this signed data, you don’t have to serve as the primary source over time.
Q: Are we still not anchored in the traditional CAs?
Justin: With parts of the Connect protocol, we took an interesting approach. If you look at keys for servers, they are published at HTTPS URLs. If it’s in the right place, the key in that location is the key that represents that party at that time. It anchors in that cert without being tied to the CA. That’s the interesting bit. You have endpoints that can enter and rotate keys as needed. Web PKI is still a problem we have to solve. But we’re not making the mistake of offloading all the trust to the CA. Avoid man in the middle. Leveraged for the application layer key discovery. That is one of the most interesting things to me that came out of Open ID Connect. It explicitly doesn’t have a trust chain built in. As I understand it, there is a lot of key addressing on the ledger than can accomplish a similar approach.
Sam Smith: If you think about data security from a common mode failure POV, you can get to low exploits by having a single layer of distributed consensus. If a majority have the same public key, the probability someone exploited all locations is so small…
Justin: Do it right is never the right answer for security.
Q: What’s the ledger equivalent of TLDs?
Nathan: I can’t speak for all the self sovereign solutions. In Sovrin it’s the name space. Search is not one answer for any key. Get a whole list of answers. You will want to search on lots of different types of attestations. From infrastructure, we haven’t picked a winner. What are you the authority over? Make attestations over that. The reality is names are contextual depending on the data involved.
Justin: Doesn’t that lead to a bunch of competing fiefdoms though? With the Internet, DNS did that for us.
Nathan: Schema anchoring on a ledger can devolve into that. Sovrin is trying to encourage flow of data. So the popularity contest serves a purpose. How do you manage a proximity of different schemas?
Justin: Avenues for innovation. In DNS the text record has been used for so many absurd things because it’s so difficult to get a DNS extension through the IETF. It means you have this bizarre free form another layer of parsers and processors to make that happen.
Nathan: You need people to make whatever attestation they want about whatever topic.
Q: How did Consumer Reports become the authority? They did reports. People liked it. Private orgs that become the defacto authority can emerge solely on their quality.
Nathan: Passports and driver’s licenses can be trusted from the beginning. The kinds of organizations you look to to bootstrap a network like a self-sovereign network. It’s a diffuse route of trust because it’s topic-specific.
Q: We’re replacing centralized trust with diffuse trust.
Justin: Reality and history dictate that developers and consumers are lazy. You will end up with static whitelists of things I trust. Employees down the line just know we’ve always done it this way.
Nathan: Self-sovereignty allows mix and match of applications. Right now they don’t have a choice because they don’t issue common schemas.
Justin: One of the biggest problems federated ID has today. I have a ton of IDPs. Those are all perfectly good. The problem is getting RPs to accept data from any of those. Efficiency pushes things toward centralization in very natural ways. The ideal is a wonderful distributed network. But the practicality of building it and deploying it at scale led to concentration.
Nathan: If we sacrifice trust and verification, we lose the ability to rebalance over time.
Q: Google Docs phishing last year. No way to verify the claims of the application or the person. That is where verifiable claims, distributed ledgers with fault tolerance can elevate the level of trust.
Justin: Something the OAuth world never really solved.
Q: Issue of ID services acting for universities that users don’t trust even though they should.
Nathan: This is why search is a good way to validate. The source of trust for signed attestations is everyone.
Q: Any tangible steps to use Open ID Connect with self-sovereign ID?
Justin: If I can get an ID token that says I am a Stanford student and check that using the verifiable claims model, that claim I am making, this hash is me, means I am a Stanford student, need to be able to have your client app do this processing. Ownership of who are Stanford students or what a student is is veriable and calculable.
Nathan: Leverage this Web of trust into your assertions. We have keys for every party in the system we can do mutual authentication.
Q: Still have to have integrity of the access channel.
Nathan: I can validate non-repudiation on the ledger...dusty threads of thoughts on Kim Cameron’s ABC of Trust.
Justin: I don’t see these two worlds merging as much as having a handful of conduits between them.
Q: Example. Tokenization of email.
Justin: One of the biggest problems with Open ID Connect in practice is people treat their email address as a global identifier. Nothing ties the email address to the issuer of an identity assertion. Therein lies something interesting. People think about themselves often as an email address. You haven’t proven any correlation between the two. In certain subdomains that’s fine. With this technology, I could lay claim to something that says I have a veriable set of attributes that I own that email address and I can get it from there.
Nathan: Instead of a Webfinger approach, we relate key material to the token for validation.
Q: We also have the problem of non-email address identifiers such as phone numbers. Allowing people to claim phone numbers.
