Note that in ProtectServe we haven’t in any way privileged the protocol interactions of a “service provider hosted at the relationship manager” — that is, the relationship manager application acting as your authorization agent can also choose to offer integrated P endpoint services, but this could be one of many Ps where you’ve chosen to store self-asserted stuff. This is one way in which your notion of A is more complex than ProtectServe’s attempt to define RMs, AMs, and SPs as distinct things (though the concept of an “agent” is obviously very useful!).

I don’t understand why an A that “aggregates attributes” from multiple Ps must necessarily break the chain of trust without a uProve type of technology. If you have the flexibility to interact with attribute authorities somewhat dynamically vs. having to pack everything into a long-lived token that must be used with many Rs, here are some ways it could be done, I think:

- Store-and-forward: Serve as an interim R (proxy R?) that consumes signed content/assertions from the original P (allowing the original P to remain blissfully unaware of which other Rs are accessing the content besides this A-and-interim-R, and allowing ultimate Rs to authenticate the data’s origin)

- Feed aggregation model: Store only a URI pointer to the original content residing at P (mediating the ability of ultimate Rs to access the URI by applying U’s policy), such that Rs can satisfy themselves that they’re talking to an authoritative party

- Full identity-enabled service model: Go whole-hog with an ID-WSF-style Discovery Service model and store a web service endpoint to the P (still mediating Rs’ access in the style mentioned just above)

Agreed on your other challenge… It’s getting to be a perma-problem by now in a lot of architectures (which makes me think: it’s Concordic!). I’m looking forward to your further thoughts.

There are two kinds of r-cards: those that are about the UA relationship and those that are about the UP relationship. I used to call the UA-related r-cards “self-issued” r-cards, but since the tokens are signed by A not by U, perhaps I should call them agent r-cards. The UP r-cards are called “3rd Party” r-cards.

You wrote “I believe many R’s will need a set of data whose pieces are individually hosted by more than one P, which is a need not currently fully served by the r-card notion.” My response is this. An agent r-card can be part of the solution. It can aggregate attributes from multiple Ps and make them available to R’s. In so doing it is acting as a information broker.

The reason I say “part of” the solution, is that a couple of challenges remain. First, without Idemix/uProve type zero knowledge proof technology the broker breaks the chain of trust from the attribute originating P to the R.

The other challenge is that (at least in the WS-SecurityPolicy and OpenID worlds) there’s no way for R to express the desired semantics. I’ll post about this separately, but there’s no way to have the R list the attributes (claims) that it requires/desires and for each individual attribute list N trusted issuers of that specific attribute.

By contrast “Information Card” technology (especially as implemented by Higgins) embraces multiple protocols including new profiles of OpenID protocol as used by a Cloud Selector. Thus if we added an I-Card column, that column could and should include a Cloud Selector in the “A” row.

Perhaps I can now use your formalism to better explain my thoughts wrt r-cards. The relationship being catered to most explicitly in ProtectServe is UR (mediated through A). For example, each R is bound by some contract in getting data that U has permissioned it to have (coming ultimately from some set of P’s). If I understand r-cards correctly, each one represents a UP relationship, not a UR relationship (the latter would involve, say, wielding a card over at some R, to which both the U and the P may have contributed data). I believe many R’s will need a set of data whose pieces are individually hosted by more than one P, which is a need not currently fully served by the r-card notion. In short, there are multiple relationships going on here.

The picture also interestingly highlights that there’s room for more user-driven contractual stuff. For example, ideally it should be possible for the user to specify a contract for each P to adhere to in sharing data on U’s instructions, and for the user to specify a contract for each A to adhere to in mediating U’s interactions.

Looking forward to more in-depth discussions with you — I’ve enjoyed our conversations in Munich and at IIW immensely!

One suggestion: in the A column for WS-*, I’d put the term “Cloud Selector” since it’s been applied to that role.

=Drummond