A number of folks have been discussing liability topics in side-email, and I wanted to share some excerpted thoughts here in preparation for Friday’s subgroup call. (Unfortunately, I can’t be on the call myself; Dazza has graciously agreed to facilitate.) The top liability/adoption conundrum I think we face is the one of whether a resource server (RS) can become comfortable with “outsourcing” protection to an authorization server (AS). An imperfect but apt analogy in the identity world is the relationship between relying parties (RPs) and identity providers (IdPs). Adrian has been describing this as wanting to define a “safe harbor” for the RS. And looking at what use cases to start with, we’ve got a healthcare elephant in the room, so I suggest we tackle it and see how it goes. :-) A pattern we’re seeing in the HEART group use cases involves Alice visiting a primary care provider (PCP) for the first time; we can imagine her offering for the PCP’s electronic health record (EHR) system to connect up to "her AS" (*more about this in a sec). So we’re just talking about very initial UMA steps here, not even a whole flow, and there don't even have to be any Bobs in the picture yet (unless he’s needed for Third-Party off-screen extra purposes). (I realize not every jurisdiction in the world has private-sector PCPs, but I believe that in some public-sector systems, private PCPs work under contract to the government — might they feel liability pressure?) *What do I mean by “her AS”? Adrian and I had a really interesting exchange about what the relationship should be between the RS, Alice, and "Alice’s AS”. His take: The RS has no right to object to whatever AS Alice wants to tell it to use, because it has no stake in the matter — it just does what the AS tells it to, it gets safe-harbor protection by getting a list of assurances that either come built-in with UMA, or are can be built on top of it (I’m not sure I understand the whole list...). My take: I really want to believe this. Obviously, what I want us to be able to build is an ironclad case for this! But an RS in real life has to act as an OAuth client to an UMA AS, has to trust that the AS actually does the right thing in coughing up tokens, that it’s secure, etc. Without those “trust framework” types of assurances, it would be crazy — or, more to the point, the CEO, CFO, and CIO of the RS operator would be crazy — to allow Alice to just point to Zeke’s Nocturnal AS (motto: “We Fly By Night”). In fact, if Alice built her own AS, it could be even shadier because she could collude with it to put lots of other people’s data at risk — the AS may end up seeing identifiers and claims of requesting parties, and maybe Alice is opening up the AS at home and looking at all the data. (Not that the RS may strictly care about these vulnerabilities, but *I* care…) In case it turns out to matter for use case exercise purposes, here are some candidate variations on the chosen AS that I identified: Alice-AS: Alice runs her own AS, whether on a home server or at her ISP or in AWS or whatever Social-AS: Alice chooses her own AS, say, run by Google or Facebook or some similar service (a la social IdPs) through a “NASCAR" interface Gov-AS: Alice uses a public-sector AS Private-AS: Alice uses the AS offered by the same closed system in which the RS runs (a la the new Privacy Control Center in Google Apps) Do the scenario, the goal, the roles, and the UMA flow give enough to work with in mapping to contractual parties? Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com