SIG-WSH Aug 08 Redmond F2F
Contents |
Attending
- F2F: Don Schmidt, Eve Maler, Conor Cahill, John Bradley, Drummond Reed
- Phone (sometimes): Brett McDowell, Paul Madsen, George Fletcher
Thanks to Don, Frank V-P, and Microsoft for hosting this meeting!
Action items
Eve: Publish the terminology alignment discussion as a separate wiki page and point the IDtbd folks to it. Conor: Report by early next week on the timeframe in which he could take part in the next-steps work.
Agenda-bashing
Let's take up the chair question more towards the end. What's the best way to get us all to the same level of education? Maybe we can do the walk-through Conor suggested for ID-WSF, and analyze the differing assumptions between it and a WS-*-based framework.
Goals
What is our goal? Conor suggests that we'll have a "profile" of WS-* specs that gives ID-WSF users features they want. Don thinks we should focus first on finding out where we can combine, or mutually profile, features that both sides are already doing.
Eve points to this diagram as a high-level comparison.
There's general agreement that this is an acceptable high-level statement. ID-WSF profiles the pieces of WS-* that it already uses, but we can discuss that as we go. ID-WSF obviously doesn't use WS-Trust today; that's maybe the biggest obvious hole.
Conor notes that ID-WSF adds interop to generic WS-* for achieving what it wants to achieve. He advocates a goal in SIG-WSH of profiling WS-* as much as we reasonably can, and ensuring that the optional parts of the (new) ID-WSF framework are made clear. Things like discovery are required to be defined for the framework to be complete, but any one deployment need not use them.
Don has counter-examples that show that WS-* isn't just building blocks, and hears from deployers that ID-WSF has more than it needs -- it's too heavy and too specific.
John reminds us that OAuth and XRDS are likely to be relevant as we look at use cases in our two worlds. It would be ideal if we could consider the underlying use cases motivating those technologies too.
We all agree that no one is suggesting that either ID-WSF or WS-*, as a whole, needs to be removed as an option where they uniquely meet someone's needs -- and they each do meet some people's needs! We in the industry have unfortunately confused a lot of people by suggesting that these things actually overlap more than they do.
We want to make the stacks much more complementary (let's not say "overlapping"!) by design, likely through a fair amount of profiling, and even possibly by recommending backwards-incompatible changes (hopefully to little-used parts of our protocol stacks) where they lead to the correct complementarity!
The ultimate goal is that all of the web services stacks interoperate, and that we'll see (e.g.) WS-Trust implementations that are compatible and composable with the profiles that emerge from this process.
Timelines and venues
Conor says, and Don agrees, that if we could propose a set of profiling work to submit to OASIS or somewhere, that would be the big win.
Eve proposes having such recommendations by the end of the year for sure. OASIS is sounding like a fine default choice for now (noting that WS-Trust, WS-Policy*, WS-Security, SAML2 from ID-FF, and even IMI have gone there), but that's still open. An existing TC? A new TC? We'll see; likely the latter.
John points out that there's an OASIS TC in the works that will focus on IMI-followup work such as defining particular token transformations.
Don reminds us that he has to go through an "OAIP" (owner/approver IP) process over whatever recommendations the SIG comes up with -- and most of us are pretty much in the same boat.
Terminology alignment
There are roughly three conceptual buckets for "identity-related" services:
- Providers: These services hand out information that is indexed by identity, on (authorized) request.
- Consumers: These services consume identity-related information (including claims that are about a non-unique identity) in order to provide differentiated service.
- Infrastructure: These services assist in the process of handling identity-related information in various fashions.
We figured out where we think claims-based service, identity-consuming service, identity-based service, identity-enabled service, and identity service go. Here's what we strongly recommend, with the new/controversial ones in bold.
- Providers
- IdP/IP (including identity selectors offering self-issued cards, cell phone-based IdPs, etc.)
- STS (most profiles of it, anyway)
- WSP (web service provider -- though note that, technically, WSP is a generic term for a responding web service)
- Attribute service
- SAML authority of any type (note that an IdP is a kind of SAML authority)
- Consumers
- RP (relying party)
- SP (service provider -- though note that, technically, an IdP is a kind of SP)
- WSC (web service consumer -- that note that, technically, WSC is a generic term for a requesting web service)
- Claims-based service: we agreed that this applies, the lion's share of the time, to the consumer side
- Identity-based service: by analogy, we agree that this means the same thing as above, but we deprecate it because it's generally confusing
- Infrastructure
- Discovery Service
- STS (generic uses)
- Interaction Service
- Identity Mapping Service, etc...
- Identity-enabled should be understood to refer to the entire set of producer, consumer, and infrastructure services
- Identity services should be understood to refer to the set of producer and infrastructure apps
Drill-down
Eve refers to a diagram (p. 5) that shows the pieces of ID-WSF also see the other helpful information in this paper.
Conor describes the SOAP Binding spec that profiles WS-Addressing, with "TargetIdentity" profiling that lets you distinguish between a target identity (say, Don's calendar), a requester (say, Conor, who wants to add an entry to Don's calendar using Don's calendar service), and the calendar service itself. Don notes that some people call this human/app distinction "delegation" (a human asking an app to do something on their behalf). WS-Trust today doesn't, by itself, support this, though you could imagine a profile for a service going and getting tokens to behave like the user. ID-WSF's Identity Mapping Service is probably closest to this approach, but for a person acting as another person, not a service doing it.
The claims-based identity approach as reflected in Zermatt expresses identity in a variety of ways. Don points to the Zermatt white paper.
Don notes that WS-MetadataExchange, WS-Transfer, and WS-ResourceTransfer got submitted to W3C just this week.
Services cooperating on behalf of one or more humans
Potential use case alert: apps acting on behalf of humans
Is this our first obvious case where some mutual profiling might be beneficial, with WS-Trust/WS-Addressing/ID-WSF SOAP-Binding/ID-WSF SecMech getting together to solve the general use case of humans asking applications to act on their behalf? In ID-WSF there are "named" and "unnamed" parties; Don is mostly interested in the "named" case. There are some "helper" headers in ID-WSF that aren't trusted (it's outside the security headers) that you can look up in order to quickly process the message -- this is for an efficiency use case. But mostly the work is done in security-related headers. OAuth essentially exists for apps to act on behalf of humans, but it doesn't have all the other security protections or expectations of policy enforcement that ID-WSF has.
Conor noted in email that "WS-Security and WS-Addressing are already profiled. There's a couple of headers that we've defined that were not clearly supported in WS-* at the time (and may still not be)." Note that SAML assertions only have room for one Subject (though you can put what Liberty calls "identity tokens" into, say, Advice).
In the WS-Trust context, if you've issued a token to a service that has delegation rights to act for a human, that token actually grants authorization. By contrast, in ID-WSF this gets requested (with data about the two identities fully present in the token) but authorization is only granted by the WSC being approached itself.
Conor observes that there are "Libertyisms" in the SOAP Binding headers that should be removed in order for all these kinds of services to be composable together.
We discussed, in the course of looking at the Authentication and SSO Services, the ability of SOAP Binding (we think) for doing updates to EPRs, in a way that's reminiscent of session keys only they're for web services.
Potential use case alert: humans acting on other humans' services
Then there's the use case of having multiple human parties involved, possibly hosted at different providers. The token needs to represent, at a minimum, that Conor is operating on Don's data that's not his own so that this can be audited. (Another scenario is customer support, where you have a support person pretending to be the customer.)
We discussed whether there's a bright line between the admin-acting-as-his-boss use case and the wife-adding-entries-to-her-husband's-calendar use case. There is one, *if* the calendar service records the action as being done (at some significant level) by the boss alone.
Delegation gives you permission to do tasks related to my data/services on my behalf (and amounts to visible or audited impersonation); mere garden-variety access control gives you permission to do tasks on my data/services on your own behalf. The semantic distinction makes a difference, e.g., for liability.
Discovery of identity-producing services
There seems to be some disagreement in the Liberty community about whether its Discovery Service is, or should be, a strong or weak PEP, or a PEP at all. Conor believes the latter. George gives an example of someone SSO'ing using a Shib ("claims-based" anonymous) model -- if you want to authorize them to get to some other service through your Discovery Service, that should work. Conor points out that the DS, when it does choose to give a WSC (requesting service) a token in order to locate the WSP (provider), the WSP always still has to authorize the WSC to get in. The DS token is just a "letter of introduction", so that the true authorization step is late-bound.
Don pushes back on the value/need for discovery of a person's services. Conor gives the example of being able to change banks in a loosely coupled fashion, even though you've given permission to some other service to charge you through "your bank" (whatever it is today, when they happen to need access it). John notes that this is a VRM use case!
John also notes that XRDS is of interest to many people as a discovery mechanism, whether instead of or in combination with an ID-WSF-style discovery service. Conor argues that it's good to preserve the ability to be dynamic in discovery, even the service locations are largely statically determined today; static IP address assignment seemed like a good idea once upon a time too! We note that XRDS is meant for public or otherwise non-access-controlled retrieval of identifier metadata (even if the identifier itself is not global or generally known) in a lightweight fashion, whereas the Discovery Service is meant for private discovery and must be bootstrapped by the target identity "connecting" first (even with an anonymous bearer token).
Don asks if it makes sense to deploy a discovery model that is scoped only to work for a virtual organization, joint venture, or other multi-domain organization -- where some people might be using on-premise services and others are coming in from the cloud. ID-WSF says nothing about the size of CoTs/federations, and scoping it down is certainly possible. The concern is a privacy/firewall one; some services perhaps shouldn't even be seeing the list of services that a DS exposes. There is flexibility in how, and when, to throttle what services a requester sees.
Conor notes that privacy has been built into the way the Discovery Service works, in that you can't use the EPR for the DS that gets passed during bootstrapping as a correlation handle, and the DS doesn't know about the attributes that are available about you. It's only there to give the location of the service provider, but not anything more about it. The DS knows which requesters have come to it, but not what they're there to do. In fact, having the ability to divide up one's identity data into multiple places (services) can be considered a privacy enhancement.
ID-SIS services and the Data Services Template
Brett notes ID-WSF provides a light wrapping around its core services, which has been conceived of as a key Liberty differentiator. The DST makes it even easier to define new value-add services when what you're doing is operating on data in a CRUD-based fashion (vs. doing work like generating tokens). You could use the DST to declare that the purpose of a service is, say, to expose a particular block of XML content.
John asks if there's a similarity between the DST and the notion of XDI data services. XDI seems to go further in dealing with fine-grained access control to the data (link contracts). However, the DST does have a basic model for access control so that it's possible to give users a reasonable interface for setting it up.
Maybe at some point we'll look closely at the DST and the ID-WSF design patterns document for additional use cases, but for now there's no need.
Mapping common claims and roles
Potential use case alert: common claims
We agree that it's useful to sync up the claims/attributes that are commonly used (e.g. in ISIP and the Personal Profile Service), but we caution that this can be an endless task and we should scope it.
Eve points out Darran Rolls's new effort called the Open Role Exchange alliance.
Drummond notes that he's working on a Community Dictionary Service -- a project of the Identity Schemas Working Group. It's a sort of Wikipedia for folksonomies.
ID-WSF services that issue tokens
Conor's conception is that the services, such as the ID-WSF Authentication Service, that currently do some kind of token issuance or exchange job without WS-Trust should be redefined to become profiles of WS-Trust to the extent possible. The candidate services, and brief explanations of them, are:
- Authentication Service (AS)
Why are we authenticating a user using ID-WSF (vs. using something like SAML)? There might be a rich-client application (say, on a laptop) -- a lowercase "wsc" -- that needs to authenticate a user before interacting with a WSP online. The AS checks user credentials and returns a DS bootstrap EPR or -- we're not sure about this -- a token that contains an EPR. The AS is based on SASL in order to allow for a variety of authentication methods.
In a WS-Trust-flavored model, it's likelier to be appropriate simply to return an AS token with a DS bootstrap EPR in it. Conor is comfortable with a token being returned in some future version, as long as he can get a DS EPR out of the token. Could <wsp:appliesTo> in the RSTR structure be used?
Currently, the AS response is a SASL response (compared to a WS-Trust RSTR structure). Is it possible to have a single WS-Trust implementation that will work for all the cases? WS-Trust already has a model for including authentication proof.
- Single Sign-On Service (SSOS)
The SSOS is somewhat similar to the AS, except that it doesn't literally authenticate the user; it just communicates with the IdP to get an SSO token.
The client might be a phone that you use to go over to Flickr. The phone needs an SSO token to log you in to Flickr, and, being a smart client, it knows where to find your IdP to pick one up (and then it uses it with Flickr's non-ID-WSF interfaces).
- Identity Mapping Service (IMS)
This service was created support multi-principal interactions. It issues "identity tokens" only (identifier information potentially unsigned, and without any implication that the principal has been authenticated, and without carrying any authorizations -- and as a consequence they may have a longer lifetime). If I want to do something to your calendar, I need to get hold of your IMS in order to learn what your identifier is at that calendar).
This can be thought of as "user-to-user federation". The IMS function is needed in a multi-service, multi-IdP, multi-principal ecosystem so that the target identity field can be populated correctly but the principal's privacy is still protected through pseudonyms.
SecMech Section 6 defines "identity tokens". Several token types are defined/profiled for this purpose.
XDI deals with this requirement using i-numbers, where you could create a different identity for each service and each i-number for each service is unique.
- Identity Provider Service (IdPS)
This service is used by the Advanced Client's Trusted Module to obtain Minting & Minted assertions (which allow the TM to act in the name of the IdP for transactions from the user's platform) -- spec.
Summary of areas to explore
The areas mentioned below all have cross-references to discussions above where relevant.
Higher-priority areas
- ID-WSF Authn Service/ID Mapping Service/SSO Service/IdP Service and WS-Trust
Note that the IdP Service is new; it's defined in the Liberty Advanced Client specs. This list of services generally relies on the security token in the header in order to function correctly (vs. putting the relevant token in the body of the request), so there's some dependency on the next couple of areas mentioned below, but there's a theoretical separation.
- ID-WSF SOAP Binding and WS-Addressing
See the discussion on services cooperating on behalf of one more humans, above.
- ID-WSF SecMech and WS-SecurityPolicy
E.g., we believe ID-WSF has a security policy saying that all Liberty headers must (or should?) be signed. How should this change? Also, ID-WSF currently profiles only the SAML token. Do we need to go beyond this?
- Discovery Service EPR metadata, WS-SecurityPolicy, and WS-Fed service metadata
This ultimately relates to ID-WSF SecMech and WS-SecurityPolicy, listed above. Don notes that WS-Fed metadata is not just for SAML-like services, but also identity services, so it should be examined for implications as well.
Although the discovery function of the Discovery Service is of less interest to Don based on what he's hearing from customers, Conor feels that the SecMech/WS-Security area can't be fully explored without also dealing with this area. John and Drummond observe that Project Higgins has an interest in discovery as a function, which can include the Discovery Service.
- Discovery Service query operation
This might express WS-SecurityPolicy as part of the operation. Note that having the DS not hand out a token at all is an option in ID-WSF, and may be closer to the expected way WS-Trust works.
See the discovery discussion, above.
Lower-priority
- XRDS and Discovery Service
See the discovery discussion, above.
This is prioritized lower because, as interesting as it is, it's secondary to the topics in the charter. Let's boil the pond first, before getting to the ocean. :-) We hope the XRDS experts among us will alert us when the discovery harmonization work is in danger of an unnecessary or unmotivated mismatch.
- InfoCard claims and ID-SIS Personal Profile Service fields
While this is lower-priority, we won't stop others from jumping in and taking a look!
- Identity selector and Interaction Service
This would make the selector a communications endpoint that the IS can use. Could XRDS have a role in helping the selector (perhaps through a browser plugin) be online and "engageable"? Are any of the Liberty "smart client" specs relevant to solving this problem?
- Infocard to ID-WSF Discovery Service bootstrapping
We anticipate that this is straightforward, in the sense that a managed card provider knows "where the Discovery Service lives" (if it isn't synonymous with it). We anticipate that this would involve authentication with a amanged card, with the bootstrap EPR in a token issued by the IP STS as a required claim. It may not make any sense to do this for a self-issued card.
Don notes that he sees strong possibilities for enterprise use of infocards, especially where a single employee has to act in multiple roles (e.g., doctors when they're prescribing, or a "floating" role of watch-commander in emergency situations). People can switch to a higher- or lower-privileged role for getting into certain apps.
Next steps
We think we're actually pretty far along in achieving the goals set out in our charter. However, we want to:
- Ensure that the work done at this F2F is reviewed and ratified, and that any new use cases get shaken out
- Get one level deeper in the educational and compare-and-contrast exercises on these technologies, possibly producing description documents for this purpose (similar to the Liberty TEG's original "WS-Addressing strawman")
- Take into account any near-term news in the identity standardization landscape
We agreed to make Don and Eve the co-chairs by acclamation. :-) We don't anticipate that there's that much work left, and Don has to do a bit of due diligence to confirm this but that's the tentative plan of record.
