IETF DIX BOF Notes Notes by Hans Granqvist, hgranqvist@verisign.com Edited by John Merrells, merrells@sxip.com Chairs: Scott Hollenbeck and John Merrells Agenda - Scott Hollenbeck agenda bashing problem/goals/benefits scope requirements architectural options/related work draft-merrells-dix-00.txt Scene setting - Bob Morgan Enterprise identity mgmt web authentication 1996 12+ solutions now: "online lives", interaction, "who's there?" now: required SSO, info exchange new goals: user-centric, deployable, 'good enough security' Definitions - John Merrells digital identity exchange client, identity agent, claim problem statement for user: manage many username passwords retyping data for service operators low conversion ratios data inaccuracy goals: automate digital exchange between user/service Discussion about Scope: Eliot Lear: references the mac os keychain -- does dix have to handle the username trying to handle this or does it have to manage credential. Doesn't want to trust the machine with keeping the credentials. Does the charter say -- we make this separations? John Merrells: separation is a requirement of what we do. Sam Hartman: needs to be in scope: interaction on how the client and the identity provider become convinced they are connecting with he right party. traditionally we've had problems making security hard and weaker then it needs to be. you seem to only need to concern client->service auth, and not other parties. Dick Hardt: how do we know the identity of the server? should infocard be inscope? Sam Hartman: yes it should. Dick Hardt: how you authenticate is out of scope, but moving the authentication result is in scope. michael slavish: about in/out scope: extend SIP to include 'peer to peer SIP' we need to read his work to see if there is any overlay. Roland (sorry no last name given): why are we here? a) you will have to define the existing digital identity schemes which are not covered in your problem statement. What is different about this to other technologies? John: this is something that isn't solved with other technologies Jeff Hodges: Why limiting to browsers? Why do I care about what the html agent is? Dick Hardt: 2 classes of problems. 1=user at the end, 2=no user at the end. dix is about 1. Jeff Hodges: it's more about user auth someone at aol (didn't get his name sorry): Don't limit to web browsers, please. scope to narrow. Include non-browser applications. Sam Hartman: Why do i need a different set of authentication scheme depending on application. We need to be aware of this. Concern is very real. Dave Crocker: a) am in favor of world peace. This topic is hard. To date all prior attempts have fallen off the wire. Distinguishing between deep discussions within architect groups vs. public discussions that need to keep usability and non-techie stuff out. need to specify a) which information needs to be standardized and b) how you move it around. so http would be a proposed model for b there is a model of interaction, requesting/exchanging information so http is one of these means. focusing on "browser stuff" is not flexible enough. John Merrells: 1) Yes, the challenge is explaining this stuff. Common language is hard. 2) We don't want to exclude any specific protocol apart from (http/html) Phillip Hallam-Baker: The objective should be how to deploy the infrastructure on the internet. *what* you deploy is not that important. saml/liberty ws-security etc are now successful inside some circles. (referencing phishing and username/password) saml/ws-security are flexible. we need a unified identifier for a user. this will dramatically simplify matters. 'URI' is the internet, not 'HTTP/HTML' John Merrells: Good point. Many username/passwords are not just inconvenience, it's a risk. Jeff Hodges: reinventing the wheel here John Merrells: If existing technology can solve this problem, then good Jeff Hodges: create new profiles! Eliot Lear: The burden is on this group to not reinvent the wheel. still not clear what you want to do. will this work with the web? yes. email? (john's opinion, no not now, maybe later) calendar? john: no eliot: you're targeting the wrong problem, you need to focus on the bits that are moved, not HOW they are moved. my concern is if you focus on http too much, you cant reproduce it in other protocols. Eric Rescorla (ecr): feels dix thinks saml wss not getting the work done Bob Morgan: There are useful scenarios with 3rd parties without authentication. is auth in scope, yes is auth always in scope, absolutely not Eric Rescorla: inscope/outscope is rat holing us. Requirements - John Merrells * move claims from agent to service * mace claims from service to agent * need a unique identifier for the user no central control, opaque, unidirectional (1:1), omni-directional (1:n), separation from identity agent * minimal disclosure * claim schema globally unique, easily extensible Sam Hartman: You need a distilled paragraph Rich Shockley: You're excluding federation which is the only thing that needs Jim Sermersheim: Goals stated and proposed charter may help people Dave Crocker: I have been in many bofs that failed and would like this to not be one of them. what i think is being asked for is this: a description of reqs and benefits, not too abstract -- how is this different from previous work, why is this worth following. now you need to adapt the agenda to cover what people want to know, not what you want to show. Bob Morgan: IETF brings these together in the past Eric Rescorla: 1) do nothing useful at all 2) if it's architecturally flawed, what is it? Dick Hardt: this slide (req -- adoption) talks to your point. how do we remove the barriers to adoptions. @leo we're not seeing dix as being SSO, it's a way of proving digital identity. Having multiple user/password is a large web 2.0 problem. Jeff Hodges: There is prior work widely adopted in different communities. Saying it isn't is widely disingenuous. Liberty already put out a pr last week. 2006 will see a billion liberty-enabled devices. saml takes 5 minutes to set up a homesite. Phillip Halam-Baker: These (slide requirements -- adoption) are more constraints than requirements. need a focused problem statement what dix brings to the table. need a statement and distribute it to saml,wss,higgins,infocard etc. and how did you solve this problem John Merrells: yes Bob Morgan: SAML community is following this. We're not fighting, we're trying to solve together. Kurt Zelenga: too many choices are the cause for shallow adoption. Wsers will not choose to adopt until there is a clear winner. blumenfeldt: The world does not a protocol to move existing digital identity. what is lacking is to define exactly what that identity is. cross enterprise is where the issues lie. problem is: how do we define this identity Eric Rescorla: on the problem statement (for user, for service operator): im gonna user srp with my own data. i feel like i m missing stuff since that solves my problem. you're missing the notion to assert claims to people with not pre-existing relationship. 1) issue claims with no prior relationship 2) the rp needs to have confidence in the claims. 3) the claims should be individually assertible 4) like to be able to assert claims about the real world. -- difference real-world claims vs. network claims -- don't understand what the problem statement. Sam Hartman: can we speak about the same thing = 3rd party claim please John Merrells: two issues a) someone will make the claim to the RP for you b) [inaudible] John Merrells: a 3rd party authority is an authoritative source will make a claim about you, we drew the claim below the third party Dick Hardt: two types of claims: self-asserted claims vs. 3rd party claims John Merrells: the agent is storing the claims Sam Hartman: does the server ever care where the agent sits? John Merrells: no Sam Hartman: no relation the identity agent and the rp John Merrells: trust = person creating claim and source consuming claim Dick Hardt: problems in digital exchange: 1) moving self-asserted data. dix is here to automate that. 2) how does a site know you're the same entity you were before. in dix, the identity agent is used for this. 3) 3rd party claims, not part Scott Hollenbeck: Are we rat holing on 3rd party claims here, ecr? Eric Rescorla: yes. Sam Hartman: why is it this complicated without 3rd party claims? Scott Hollenbeck: are ecr's 4 statement list not unique? rob: need to differ self-asserted and authority-asserted stuff Sam Hardtman: ecrs list has nothing to do with uniqueness Phillip Hallam Baker: the piece that is missing is a uniform identifier. there are 2 scope discussions: 1) what is in scope for this group? 2) what is in scope for discussion? 3rd party claims exist: x509 and saml. Love: one thing is unique -- simplicity. simple is a good start. Jeff Hodges: a bunch of prior work on identifiers. specifically XRI. blumenfeldt: perhaps we want to specify the deployment scope. will it be used in a limited part of the enterprise, etc. Scott Hollenbeck: is this uniqueness? blo: no, it's usability. if the scope is too narrow and limited it may not be useful. so to figure out if we want to spend efforts on this, let's first figure out if the scope is big enough Lisa: internet scope blu: that scope is big enough. Ben Laurie: another requirement. identity mgmgt systems should be privacy conserving. claims need to be unlinkable. none of the existing things do that. jeff hanton(?): can there be correlation between claims. is it a requirement to handle that? John Merrells: yes, part of privacy requirements. mike richardson: there was a spki group 10 years ago. prior to the xml rage. at the time, 3rd parties could make statements that were going to reduce the burdens on the users. we're trying to do the same thing here. x509 keys work for million user scenarios, but fail person-to-person scenarios. this is what i see missing from dix. most of us haven't touch liberty/saml on a regular basis, so we don't know if this is simple with these technologies. conclusion: i dont really know what we're doing here. John Merrells: key differentiator: p2p -- Eliot Lear: is the solution predicated on the uniqueness of the identity? John Merrells: we need a unique identifier Eliot Lear: why? Dick Hardt: so that service knows who it is Eliot Lear: it needs to be unique to a service. i am questioning the scope. Dick Hardt: sometimes you want to prove the same person to a set of sites. one of the things we think is unique here. Eliot Lear: the liberty alliance doesn't provide that? Jeff Hodges: we (liberty) figured out how to do that. public unique identifiers are not necessary. there are ways of doing this without Dave Crocker: 3 tasks: 1) a statement of the problem and the nature of the solution that is crisp and tight so that anyone can understand. 2) need a matrix of prior work for emotional investment, and statements why dix is better 3) usage scenarios that show how dix is different. last point: scaling is fundamental -- things that can be successful in enterprises often fail on the internet. Lisa: need to figure out the dix problem statement, not the dix technology 1) how can you be unique to services without have unique identifier? Phillip Hallam-Baker: i get worried about "what the world is pgp" instead of saying "what the world needs is a way of sending secure mail from a to b". the blog user case wasn't discussed when saml/liberty and wss were discussed Dick Hardt: @lisa saml requires implicit trust issuer and verifier. so it doesn't scale. liberty depends on a single identity provider. Jeff Hodges: pair wise identifiers in samlv2 can be completely hidden from the user. Scott Hollenbeck: let's look at the uniqueness slide: 1 unified approach to self and authority stated claims (Bob) 2 'Friendly' Multiple portable unique identifier for user (phil/dick/lisa) 2a many identifiers for users 3 simple and easy to deploy and adopt (love) 4 p2p exchange of identity information(?) 5 privacy 6 use case: blogosphere. not satisfied by existing technology? (phil) 7 internet scale for trust Lisa: need plural identifiers Phillip Hallam-Baker: relationship identifiers -> users needs to be N:1 Bob Morgan: there are today temporal identifiers that stop working after a Time Jeff Hodges: some things are not unique Scott Hollenbeck: the sum 1--7 should constitute the uniqueness Phillip Hallam Baker: xri: have hammer, have 30 mill VC capital, gonna well damn we'll find a nail Sam Hartman: this is a rat hole. i dont care if it's the 53th invention of the wheel. if it is useful, then it is useful. Scott Hollenbeck: i want to come up with a statement that combined is a statement of something to be solved. blumenfeldt: not about uniqueness. more like why is it going to succeed. Dave Crocker: by comparing to prior work is how we find out what to do. the uniqueness exercise is the input to the process. Phillip Hallam-Baker: portable identifiers need to be user oriented not mechanism oriented. Patrik Folstom: need to make as distinction between moving . cookies are very easy to do uniqueness, so we need to specify use case. Scott Hollenbeck: this looks like a TBD. Lisa, how do we continue? Lisa: if people think we can get consensus in the room, it would help guiding. can we change opinions into statements and see what consensus is? Sam Hartman: is this problem statement very different from the one we had coming in? John Merrells: it's a restatement. what i have is a spec that i believe solves these problems Sam Hartman: it adds complexity by solving more problems Eliot Lear: i need a way form my dad to securely access websites without having multiple passwords all over the place. Rich Shockley: i wish this bof would go away and never come back consensus: no Patrick Faltstrom: technical/business case problem are different. Lewinski: strongly agree with eliot's dad problem. Jeff Hodges: pop up the stack -- gee maybe it's useful to look at deployment profiles of existing stuff. that should be up there on the list. eliot's dad consensus: yes "reusing existing technology where appropriate?" consensus: yes Phillip Hallam Baker: existing standards atom/http are on the behest of IETF so we should discuss from these terms. Eliot Lear: we want to minimize the dependencies on 3rd parties. should what dix does minimize 3rd party dependencies? steve young(?): the web site operator p.o.v. should be able to figure out if someone comes back under another identity Dave Crocker: The "ed protocol" we develop and agree on 3-5 scenarios for which we believe there is need and existing technologies cannot solve Mike Richardson: front-end standard needed. back-end (mysql, ldap, etc) exists. it may be worth stating what tech exists ("SHOULD" in docs) Eliot Lear: what about hardware authenticators? lisa walks thorugh the consensus points questions is there zero new work here? wolfgang, deutsche telekom: these things are already solved in liberty/saml lisa: dmd -- is dix failing to use highly appropriate and working technology? consensus: 50/50 is more work on reqs and use cases useful? cosensus: yes Scott Hollenbeck: In closing, we clearly don't have enough consensus to start talking about working groups, charter, etc. We seem to have some facets in order, and some points in place to work on, take it back to the list and continue work. Note that the IETF only allows BOFs twice, so if you're not done in Montreal, you're out.