SIG-WSH 21 Nov 08 telecon

Liberty Alliance Project
WSH SIG
Teleconference Meeting Minutes
November 21, 2008
1 hr 10 mins
Author: Eve Maler & Kurt Kolok

Attendance:

Eve Maler, Sun
John Bradley, ooTAO
Jonas Hogworth, Ericsson
Paul Madsen, NTT
Don Schmidt, Microsoft
Hubert Le Van Gong, Sun
George Fletcher, AOL

Brett McDowell, Liberty Staff
Kurt Kolok, Liberty Staff

Note: only Liberty members can see the actual slides on the LAP site documenting the submission proposal we're discussing today.

Brett reports: This SIG and its conversation in Redmond finally spurred a serious effort in the LAP Technology EG to figure out how to move its mature ID-WSF specs forward in an appropriate venue, including an effort to harmonize them with relevant WS-* specs. OASIS was agreed to be the appropriate venue, and the proposal on how to break down the specs and submit them has been approved. Now the task is to actually do the submission, and coordinate with the individual co-authoring companies that are in a position to sponsor new TCs and propose appropriate scopes for them. (LAP per se wouldn't do this; it needs to be indirect in this fashion due to the respective venues' rules.)

The set of TCs being proposed are, in what's intended to be chronological order (with TC names entirely up for discussion!):

1. "SOAP-based IdM Messaging" TC, to receive:

• SOAP Bindings (already leverages WS-Security)
  ‏
• SecMec (may leverage WS-SecurityPolicy)
  
  

SOAP Bindings defines the headers and security model needed for an identity services call. SecMec allows a web services consumer (WSC -- requestor) to come to agreement around security choices with a web services provider (WSP -- responder).

The thinking around this being the first TC to be proposed is that it is relatively standalone and generally applicable. The work that SOAP Bindings does is being independently invented all over the place, so it would be nice to have one place for it.

SOAP Bindings has a lot of LAP-specific headers, some of which are motivated by features other than security. Some headers could perhaps be changed to use more-standard headers where they exist; this would be legitimate TC work. The functionality provided by the headers, however, needs to be retained.

One general design principle is to change existing spec features if necessary for harmonization purposes, but not doing a complete refactoring for the heck of it. Overloading existing headers with wholly new semantics doesn't provide a harmonization savings, but we should look for both new features of WS-* specs since their standardization, and also conventions that have grown up around usage of WS-* that may not be captured in those specs.

Why make a whole TC about a binding? The name of the original ID-WSF spec is misleading (it was named presuming the context of the spec stack that surrounds it), and the TC name being proposed doesn't include the word "binding".

Another general design principle is to ensure that independently useful features buried in ID-WSF should be made more composable!

2. "IdM Services TC", to receive:

• AS, SSOS, IMS, IDPS (intended to leverage WS-Trust) [said "may" leverage in email; updated to reflect the email conversation thread]
  
  ‏

These are the security-focused services within ID-WSF that logically imply token exchange. Currently they aren't defined as profiles of WS-Trust, but that's the intended mechanism for them in future. Most of these specs actually appear in a single ID-WSF spec.

Note that today's Discovery Service combines two jobs: discovery of an endpoint and issuing a token to gain access to that endpoint. The IdP Service could be called, in composable fashion, by the Discovery Service as its token-issuing service; this is the "Denmark use case".

It is anticipated that, though four service specs would be submitted, the number of output specs could easily be fewer, and they're likely to be fairly thin profiles on top of WS-Trust. The goal isn't to map specs one-to-one into TCs; the effort was made to identify a logical composition that better matches the WS-* functionality.

3. "Identity Services Lookup" TC, to receive:

• Discovery Service
  
  

This is the logical discovery piece of the Discovery Service (vs. the token issuance piece discussed above). In the past, UDDI had been mentioned as relevant, though the design centers of the two seemed not to match. XRDS seems to be more relevant. John notes that Google and Bob Morgan have joined the XRI TC because of their interest in XRDS, and even Dave Orchard may join. And there's an infocard identity selector that's using XRD cleverly.

Historical note: YADIS (then Yadis) became XRDS-Simple, which is in the process of becoming "XRD" (though it may end up being a series of XRDs, that is, an XRDS). XRDS and its XRD data-structure component have continued to be standardized in the XRI TC. The XRDS universe provides a discovery format and a tiny bit of protocol for discovery of itself (and there was some uncompleted work around discovery descriptor provisioning), while the Discovery Service provides a protocol.

Given that the XRI TC's work is now relatively cleanly split into XRI Syntax and the XRDS stuff, does it make sense to contemplate an XRDS and Discovery Service "merger", if their use cases can be accommodated? The Discovery Service today returns an endpoint, leveraging WS-Addressing. XRDS doesn't leverage it at all. A nice harmonization picture could be made out of an XRD-based format and an abstract protocol with both SOAP-based (with WS-Addressing) and RESTful bindings. Let's do some focused outreach on this specific idea, to see if it's worth pursuing. Harmonization with WS-* has been the primary focus of this SIG, and XRD harmonization would be "bonus" but secondary according to our plan of record.

The IDTrust Member Section puts in a bid for holding these new TCs!

Action: Paul and John to put together a strawman for discussion at a follow-on focused SIG-WSH call about discovery/lookup.

Action: John and the TEG reps to pursue focused inquiries with their communities about discovery/lookup harmonization.<b>

<b>4. "User Interaction" TC, to receive:

• Interaction Service and the interaction redirect mechanism
  
  

The redirect mechanism involves some headers to control the interaction.

5. "Relationship Management" TC, to receive:

• People Service
  
  

The name of this TC might suggest (wrongly?) a connection with VRM work. But this is just intended to be around this one service, which helps you manage your social contacts, or what might be called "user-to-user federations". It's logically similar to the Portable Contacts API, but has a different privacy model.

Note that the XDI TC defines an abstract service for personal datastores, which may be relevant.

Another way to see this service is as a "groups and roles" services, apart from whether they contain people/individual identities or not.

This ID-WSF service in particular is especially sensitive to scoping/use case choices, in terms of what it should be harmonized with and where/how it should be standardized.

Action: Eve to ask Brett for a timeline on when the LAP slides (or a facsimile) can be made public.

Meeting Adjourned