On Tue, Mar 21, 2006 at 03:12:37PM -0500, Robert Yates wrote: > So from what I could make out DIX requires a set of use cases and a > concrete reason why SAML et al doesn't cut it. I thought I'd give it a > go while this is all fresh in my mind. > > Use Cases > > 1. Elliot's dad wants one userid and password for the web.
But in practice not every service will join the same federation, so I suspect that for market reasons we can do no better than a small number of identities and credentials, each for a set of many services. > 2. Elliot's dad wants to stop retyping his credit card information and > shipping address every time he wants to buy something on the web Note that Elliot's dad almost certainly has multiple credit cards and will sometimes want to use one and sometimes another, and there won't be a pattern the browser/whatever can discern (e.g., "this card's balance got too high and I'll carry some over, so let's make charges on this other card for a while"). In other words: the identity selection problem simply won't go away, and at the limit always requires human interaction. > 3. Elliot's dad wants to share his online pictures with me and elliot > (and only me and elliot) > 4. I want to subscribe to Elliot's dad's photocast so that as new photos > become available they are automatically downloaded to my machine. > http://www.apple.com/ilife/iphoto/features/photocasting.html By "automatically downloaded" in (4) I assume you also mean "when I'm not around," by which you would probably mean that you want some form of authentication mechanism/credential that doesn't require human interaction to use. Have I guessed correctly? > 5. I want to print Elliot's dad's photos using a web photo printing > website. The web site that I use to print the photos is different to > the one that stores the photos. > > Observations > > 1&2 are accommodated by dmd1 and SAML, Liberty Alliance et al. SAML > however requires some previous relationship between homesite and > membersite (is this true? do they need a common CA?) > 3. is almost covered by dmd1 and SAML but I still don't understand how I > either get the persona-url from an e-mail or an e-mail from a persona-url. Presumably you'd be signing these e-mails somehow, no? S/MIME, or PGP? :) > 4 is not presently covered by dmd1 or SAML (AFAIK). I honestly believe > that authentication via feedreaders and other "rich clients" are a MUST > have requirement. If the blogosphere forms part of the justification > for DIX then not allowing bloggers to make blog postings using a rich > client over atompub > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt > seems wrong. Phillip's suggestion around federated digest seems to make > a lot of sense. If use case 4 makes it into the list of requirements > for DIX then this would seem to be a significant differentiator between > it and SAML. DIX can do REST, SAML can only do Web Services and we all > know how popular those are at the moment > http://www.loudthinking.com/arc/000575.html. I don't see why SAML can't handle (4), assuming I guess correctly what you meant by (4), since SAML doesn't handle authentication mechanisms directly, so that as long as you can authenticate to your IdP with some mechanism/credential that requires no interaction then SAML should not require interaction either. Nico -- _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
