On 20-Jan-06, at 8:13 PM, Phil Hunt wrote:
John Directory Centric Model doesn't work?
Well, I didn't make quite as bold a statement as that, but within the context of end users roaming about on Internet it hasn't helped them create a portable digital identity...
I agree completely. Pretty amazing for an LDAP guy! However, I would argue strongly that both the directory repository (database or whatever) and the user centric model are needed.
Yes indeed.
Example, you have your driver's license, but the government has a database that has all the details on all licenses issued and whether it is revoked and how many points you have lost (gee...starting to sound like PKI all over again ;-) ).
Maybe not the best example, but if I were a government agency then the DCM might work for me because I have the connections and the expertise to establish the trust and federation relationships to make it work. But if I'm putting up website to be an intermediary between users and insurance companies then the UCM is probably better... I might ask the user to provide me with a claim that within a year they've held a clean license. The user might already have one... or they can go get one from the state government from where ever they reside. Much quicker and cheaper and possibly as realtime as needed to get an insurance quote... right now that's all self asserted... so this is better.
Also, no matter what happens with directory or identity exchange, there will always be the application that has to store data. Where this all breaks down is what happens when the application needs to maintain context.
Don't really grok that. They app can store it's session or user associated state local to itself, on the users client if it allows it (cookie), in it's own property in the agent (if the user allows it). (In dmd1 we even allow state to be added to the request message for return with the response message.)
In this sense, I'm worried about what happens when the user chooses to present a different credential each time.
Do you mean identifier? That's a good thing for the user.
This actually makes life for the application programmer even more difficult.
Makes no difference. Makes it harder for them to track the user across space and time, which is a good thing. If they want to do that they should negotiate it with the users like the supermarkets do in meat space. Customer tracking card for a 5% discount, sir? yes please don't mind if I do.
In the end he has to ask more questions like what is your social sec number or SIN. Hmmm....pretty soon we end up repeating history.
User's won't accept that, so app programmer won't do it. They'll have to offer the users something in return for tracking them.
The key is NOT to build a system that is 100% one way or the other. The huge uber directory definitely won't work. Neither will the "user" uber-card.
Sure, horses for courses.
What we need is an easy-to-use and manage and safe system that combines the 7-laws and the correct mix of technologies. Just like routers made it easy to inter-connect discreet networks into the huge global network we take for granted, we really need an ecosystem to link assertions and authorities in verifiable, portable, and secure ways.
Here here.
I think there are really two macro profiles to think about -- "Session" and "Storage" modes. Session mode is really where we see SAML, SXIP and others playing (the 2.0 team) - where one application wants to pass data or assertions on to another service with a portable assertion. The still important "storage mode" is where all the authoritative stores that comprise the permanent data goes to and comes from when the session based application needs to assert or consume something.
Well yes, there's protocols, and there's endpoints.... that's pretty much a given.
Do you work for a storage company Phil? :-P John _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
