From Eve.Maler at Sun.COM Thu Nov 6 12:11:13 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Thu, 06 Nov 2008 12:11:13 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP Message-ID: Hi folks-- I'd like to schedule a teleconference after the current Liberty meeting in Tokyo and after the IIW meeting next week, to get up to speed on plans to submit ID-WSF components elsewhere and to discuss our SIG's next steps. Please take LESS THAN ONE MINUTE to follow this link and fill out your preferences for a telecon time: http://doodle.com/hr7c6vgzm5kznikw Note that this poll offers timezone support; you can change the display to show your home timezone for convenience. If people can respond by mid-next week, I will send out call details with the winning time slot. Thank you! Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From Eve.Maler at Sun.COM Tue Nov 11 10:12:22 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 11 Nov 2008 10:12:22 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP!! In-Reply-To: References: Message-ID: <36557076-A645-4651-8136-C62CA7C42FD1@sun.com> Last call for your responses to the doodle poll! By my COB tonight, I'll send out the winning timeslot and dial-in details. Hoping to hear from Don and Brett, if possible. Eve On Nov 6, 2008, at 12:11 PM, Eve Maler wrote: > Hi folks-- I'd like to schedule a teleconference after the current > Liberty meeting in Tokyo and after the IIW meeting next week, to get > up to speed on plans to submit ID-WSF components elsewhere and to > discuss our SIG's next steps. > > Please take LESS THAN ONE MINUTE to follow this link and fill out your > preferences for a telecon time: > > http://doodle.com/hr7c6vgzm5kznikw > > Note that this poll offers timezone support; you can change the > display to show your home timezone for convenience. If people can > respond by mid-next week, I will send out call details with the > winning time slot. > > Thank you! > > Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From donsch at windows.microsoft.com Tue Nov 11 12:16:47 2008 From: donsch at windows.microsoft.com (Don Schmidt) Date: Tue, 11 Nov 2008 12:16:47 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP!! In-Reply-To: <36557076-A645-4651-8136-C62CA7C42FD1@sun.com> References: <36557076-A645-4651-8136-C62CA7C42FD1@sun.com> Message-ID: <60BD80BD555E91479F996CCB05EB8498134DA2F3BA@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Eve, I am on business in Europe. My return date to US is in flux as I have additional requests from customers for meetings. I do not know for certain when I will be back in Redmond and my days here are fully booked. I may be available towards the end of next week, but cannot confirm. --des -----Original Message----- From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Eve Maler Sent: Tuesday, November 11, 2008 7:12 PM To: sig-wsh at lists.projectliberty.org Subject: Re: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP!! Last call for your responses to the doodle poll! By my COB tonight, I'll send out the winning timeslot and dial-in details. Hoping to hear from Don and Brett, if possible. Eve On Nov 6, 2008, at 12:11 PM, Eve Maler wrote: > Hi folks-- I'd like to schedule a teleconference after the current > Liberty meeting in Tokyo and after the IIW meeting next week, to get > up to speed on plans to submit ID-WSF components elsewhere and to > discuss our SIG's next steps. > > Please take LESS THAN ONE MINUTE to follow this link and fill out your > preferences for a telecon time: > > http://doodle.com/hr7c6vgzm5kznikw > > Note that this poll offers timezone support; you can change the > display to show your home timezone for convenience. If people can > respond by mid-next week, I will send out call details with the > winning time slot. > > Thank you! > > Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. _______________________________________________ Sig-wsh mailing list Sig-wsh at lists.projectliberty.org http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org From Eve.Maler at Sun.COM Tue Nov 11 14:36:35 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 11 Nov 2008 14:36:35 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP!! In-Reply-To: <60BD80BD555E91479F996CCB05EB8498134DA2F3BA@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <36557076-A645-4651-8136-C62CA7C42FD1@sun.com> <60BD80BD555E91479F996CCB05EB8498134DA2F3BA@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Hi Don-- I understand how these things go, and appreciate the note! Will try to pick a time that you *may* be able to join... Eve On Nov 11, 2008, at 12:16 PM, Don Schmidt wrote: > Eve, > > I am on business in Europe. My return date to US is in flux as I > have additional requests from customers for meetings. I do not know > for certain when I will be back in Redmond and my days here are > fully booked. I may be available towards the end of next week, but > cannot confirm. > > --des > > -----Original Message----- > From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org > ] On Behalf Of Eve Maler > Sent: Tuesday, November 11, 2008 7:12 PM > To: sig-wsh at lists.projectliberty.org > Subject: Re: [Sig-wsh] Telecon for SIG-WSH next steps: RSVP!! > > Last call for your responses to the doodle poll! By my COB tonight, > I'll send out the winning timeslot and dial-in details. Hoping to > hear from Don and Brett, if possible. > > Eve > > On Nov 6, 2008, at 12:11 PM, Eve Maler wrote: > >> Hi folks-- I'd like to schedule a teleconference after the current >> Liberty meeting in Tokyo and after the IIW meeting next week, to get >> up to speed on plans to submit ID-WSF components elsewhere and to >> discuss our SIG's next steps. >> >> Please take LESS THAN ONE MINUTE to follow this link and fill out >> your >> preferences for a telecon time: >> >> http://doodle.com/hr7c6vgzm5kznikw >> >> Note that this poll offers timezone support; you can change the >> display to show your home timezone for convenience. If people can >> respond by mid-next week, I will send out call details with the >> winning time slot. >> >> Thank you! >> >> Eve > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From Eve.Maler at Sun.COM Tue Nov 11 17:00:07 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 11 Nov 2008 17:00:07 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 Message-ID: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> I apologize that a time slot accommodating everyone wasn't available, but in order to maximize the chance that Don can participate, and to give Jonas a bit of time in case he's able to rearrange his schedule :-), let's meet at the following coordinates: Friday, 21 November 2008 10am PT/1pm ET/7pm CET +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# We'll focus on the submission details for now, and review the technology areas identified at our SIG-WSH face-to-face meeting. We can perhaps also discuss whether any topics from IIW should/do impact the submission plans. We can schedule a later meeting to do a deep-dive on Jonas's use cases (and I'd welcome seeing the presentation he mentioned, if he's able to send it to the list). Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From Eve.Maler at Sun.COM Wed Nov 12 08:09:01 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Wed, 12 Nov 2008 08:09:01 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 In-Reply-To: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> Message-ID: <4B939A0F-1143-4DA9-826B-F63A359F1FAD@sun.com> Oops, sorry, I didn't mean Jonas, I meant S?ren Peter Nielsen... The latter sent mail back in September and offered more detail in slide form. Eve On Nov 11, 2008, at 5:00 PM, Eve Maler wrote: > I apologize that a time slot accommodating everyone wasn't > available, but in order to maximize the chance that Don can > participate, and to give Jonas a bit of time in case he's able to > rearrange his schedule :-), let's meet at the following coordinates: > > Friday, 21 November 2008 > 10am PT/1pm ET/7pm CET > +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# > > We'll focus on the submission details for now, and review the > technology areas identified at our SIG-WSH face-to-face meeting. We > can perhaps also discuss whether any topics from IIW should/do > impact the submission plans. > > We can schedule a later meeting to do a deep-dive on Jonas's use > cases (and I'd welcome seeing the presentation he mentioned, if he's > able to send it to the list). > > Eve > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From spn at itst.dk Mon Nov 17 03:19:42 2008 From: spn at itst.dk (=?iso-8859-1?Q?S=F8ren_Peter_Nielsen?=) Date: Mon, 17 Nov 2008 12:19:42 +0100 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 In-Reply-To: <4B939A0F-1143-4DA9-826B-F63A359F1FAD@sun.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> <4B939A0F-1143-4DA9-826B-F63A359F1FAD@sun.com> Message-ID: Hi Eve - Yes- here are som slides providing background on the potential in using identity/claims based web services in self service applications /S?ren P -----Oprindelig meddelelse----- Fra: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] P? vegne af Eve Maler Sendt: 12. november 2008 17:09 Til: Eve Maler Cc: sig-wsh at lists.projectliberty.org Emne: Re: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 Oops, sorry, I didn't mean Jonas, I meant S?ren Peter Nielsen... The latter sent mail back in September and offered more detail in slide form. Eve On Nov 11, 2008, at 5:00 PM, Eve Maler wrote: > I apologize that a time slot accommodating everyone wasn't available, > but in order to maximize the chance that Don can participate, and to > give Jonas a bit of time in case he's able to rearrange his schedule > :-), let's meet at the following coordinates: > > Friday, 21 November 2008 > 10am PT/1pm ET/7pm CET > +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# > > We'll focus on the submission details for now, and review the > technology areas identified at our SIG-WSH face-to-face meeting. We > can perhaps also discuss whether any topics from IIW should/do impact > the submission plans. > > We can schedule a later meeting to do a deep-dive on Jonas's use cases > (and I'd welcome seeing the presentation he mentioned, if he's able to > send it to the list). > > Eve > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.project > liberty.org Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. _______________________________________________ Sig-wsh mailing list Sig-wsh at lists.projectliberty.org http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty .org -------------- next part -------------- A non-text attachment was scrubbed... Name: DK-background-req4Basic-idws-v02.ppt Type: application/vnd.ms-powerpoint Size: 2394624 bytes Desc: DK-background-req4Basic-idws-v02.ppt URL: From Eve.Maler at Sun.COM Thu Nov 20 11:19:15 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Thu, 20 Nov 2008 11:19:15 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 In-Reply-To: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> Message-ID: <74226FFD-1656-44B9-AF11-D2963DD0E0FB@sun.com> Reminder: We're meeting tomorrow. Talk to you then! On Nov 11, 2008, at 5:00 PM, Eve Maler wrote: > Friday, 21 November 2008 > 10am PT/1pm ET/7pm CET > +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# > > We'll focus on the submission details for now, and review the > technology areas identified at our SIG-WSH face-to-face meeting. We > can perhaps also discuss whether any topics from IIW should/do > impact the submission plans. > Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From donsch at windows.microsoft.com Thu Nov 20 13:10:09 2008 From: donsch at windows.microsoft.com (Don Schmidt) Date: Thu, 20 Nov 2008 13:10:09 -0800 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 In-Reply-To: <74226FFD-1656-44B9-AF11-D2963DD0E0FB@sun.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> <74226FFD-1656-44B9-AF11-D2963DD0E0FB@sun.com> Message-ID: <60BD80BD555E91479F996CCB05EB849816243E8285@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Eve, Thanks for the scheduling consideration. I am back in the office and will be on the call. --des -----Original Message----- From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Eve Maler Sent: Thursday, November 20, 2008 11:19 AM To: sig-wsh at lists.projectliberty.org Subject: Re: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 Reminder: We're meeting tomorrow. Talk to you then! On Nov 11, 2008, at 5:00 PM, Eve Maler wrote: > Friday, 21 November 2008 > 10am PT/1pm ET/7pm CET > +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# > > We'll focus on the submission details for now, and review the > technology areas identified at our SIG-WSH face-to-face meeting. We > can perhaps also discuss whether any topics from IIW should/do > impact the submission plans. > Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. _______________________________________________ Sig-wsh mailing list Sig-wsh at lists.projectliberty.org http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org From brett at projectliberty.org Fri Nov 21 04:35:07 2008 From: brett at projectliberty.org (Brett McDowell) Date: Fri, 21 Nov 2008 07:35:07 -0500 Subject: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on Fri, Nov 21 In-Reply-To: <60BD80BD555E91479F996CCB05EB849816243E8285@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> <74226FFD-1656-44B9-AF11-D2963DD0E0FB@sun.com> <60BD80BD555E91479F996CCB05EB849816243E8285@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <1E10C523-8728-4C59-8829-C5A64BED70F7@projectliberty.org> I will also be on the call. On Nov 20, 2008, at 4:10 PM, Don Schmidt wrote: > Eve, > Thanks for the scheduling consideration. I am back in the office > and will be on the call. > --des > > -----Original Message----- > From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org > ] On Behalf Of Eve Maler > Sent: Thursday, November 20, 2008 11:19 AM > To: sig-wsh at lists.projectliberty.org > Subject: Re: [Sig-wsh] Telecon for SIG-WSH next steps: 10am PT on > Fri, Nov 21 > > Reminder: We're meeting tomorrow. Talk to you then! > > On Nov 11, 2008, at 5:00 PM, Eve Maler wrote: > >> Friday, 21 November 2008 >> 10am PT/1pm ET/7pm CET >> +1 866 545 5227 or +1 215 446 3648 or x44410, code 270-9441# >> >> We'll focus on the submission details for now, and review the >> technology areas identified at our SIG-WSH face-to-face meeting. We >> can perhaps also discuss whether any topics from IIW should/do >> impact the submission plans. >> > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org > > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org From Eve.Maler at Sun.COM Fri Nov 21 10:05:59 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Fri, 21 Nov 2008 10:05:59 -0800 Subject: [Sig-wsh] Location of latest LAP submission proposal slides Message-ID: <9CAADEE7-1CF8-463F-BDB6-84873BE17BB0@Sun.COM> https://maa.projectliberty.org/lap-technology/public-mail-msg?t=128312900003 I believe you need a LAP login to see the attachment. Here is the link to the notes from our F2F on our own wiki: http://wiki.projectliberty.org/index.php/SIG-WSH_Aug_08_Redmond_F2F Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From Eve.Maler at Sun.COM Fri Nov 21 11:07:32 2008 From: Eve.Maler at Sun.COM (Eve Maler) Date: Fri, 21 Nov 2008 11:07:32 -0800 Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon In-Reply-To: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> Message-ID: Attending: Eve Maler, Brett McDowell, Kurt Kolok, John Bradley, Jonas Hogberg, Paul Madsen, Hubert Le Van Gong, Don Schmidt, George Fletcher Notes from last meeting: http://wiki.projectliberty.org/index.php/SIG-WSH_Aug_08_Redmond_F2F Note that 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 it 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: It's 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 (may leverage WS-Trust)? 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's 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! AI: Paul and John to put together a strawman for discussion at a follow-on focused SIG-WSH call about discovery/lookup. AI: John and the TEG reps to pursue focused inquiries with their communities about discovery/lookup harmonization. 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. AI: Eve to ask Brett for a timeline on when the LAP slides (or a facsimile) can be made public. Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From donsch at windows.microsoft.com Sun Nov 23 10:20:15 2008 From: donsch at windows.microsoft.com (Don Schmidt) Date: Sun, 23 Nov 2008 10:20:15 -0800 Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon In-Reply-To: References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> Message-ID: <60BD80BD555E91479F996CCB05EB849816243E8AEF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Eve, Bret I am confused by the highlighted comment after the second TC in the mail below. 2. "IdM Services TC", to receive: - AS, SSOS, IMS, IDPS (may leverage WS-Trust)? It was my understanding that the harmonization of these WF specs with WS-Trust was one of the two major goals of SIG-WSH. That was a significant part of the first SIG-WSH face-face meeting discussions. Conor explained in detail where there were obvious points for WSF token issuing services to be revised to maximize re-use of WS-Trust. This was captured in the WIKI minutes which I pasted in below for easy reference. The highlighted annotation for this TC appears to indicate a significant departure from the original SIG-WSH proposal for harmonization. Can you please confirm if the plan for this TC has been changed? And if so why? Thx -- des 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: [X] 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 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. [X] 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). [X] Identity Mapping Service (IMS) [X] ? [X] Identity Provider Service (IdPS) [X] ? -----Original Message----- From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Eve Maler Sent: Friday, November 21, 2008 11:08 AM To: sig-wsh at lists.projectliberty.org Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon Attending: Eve Maler, Brett McDowell, Kurt Kolok, John Bradley, Jonas Hogberg, Paul Madsen, Hubert Le Van Gong, Don Schmidt, George Fletcher Notes from last meeting: http://wiki.projectliberty.org/index.php/SIG-WSH_Aug_08_Redmond_F2F Note that 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 it 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: It's 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 (may leverage WS-Trust)? 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's 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! AI: Paul and John to put together a strawman for discussion at a follow-on focused SIG-WSH call about discovery/lookup. AI: John and the TEG reps to pursue focused inquiries with their communities about discovery/lookup harmonization. 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. AI: Eve to ask Brett for a timeline on when the LAP slides (or a facsimile) can be made public. Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. _______________________________________________ Sig-wsh mailing list Sig-wsh at lists.projectliberty.org http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From conor.p.cahill at intel.com Sun Nov 23 11:22:39 2008 From: conor.p.cahill at intel.com (Cahill, Conor P) Date: Sun, 23 Nov 2008 11:22:39 -0800 Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon In-Reply-To: <60BD80BD555E91479F996CCB05EB849816243E8AEF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> <60BD80BD555E91479F996CCB05EB849816243E8AEF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <97D5E1BB8FC13D4EA3B34BAE8E6898C92F53AB97@orsmsx508.amr.corp.intel.com> The plans haven?t changed in any substantial way. I think the ?may? was inserted to indicate that it?s still possible that we could *possibly* run into issues mapping features/functionality with the current WS-Trust spec (e.g. the work isn?t done yet). If you look later into the description under that item you can see ?Currently they aren't defined as profiles of WS-Trust, but that's the intended mechanism for them in future.? So it is intended to use WS-Trust (as we discussed at the SIG-WSH F2F). Conor From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Don Schmidt Sent: Sunday, November 23, 2008 1:20 PM To: Eve Maler; sig-wsh at lists.projectliberty.org Subject: Re: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon Eve, Bret I am confused by the highlighted comment after the second TC in the mail below. 2. "IdM Services TC", to receive: - AS, SSOS, IMS, IDPS (may leverage WS-Trust)? It was my understanding that the harmonization of these WF specs with WS-Trust was one of the two major goals of SIG-WSH. That was a significant part of the first SIG-WSH face-face meeting discussions. Conor explained in detail where there were obvious points for WSF token issuing services to be revised to maximize re-use of WS-Trust. This was captured in the WIKI minutes which I pasted in below for easy reference. The highlighted annotation for this TC appears to indicate a significant departure from the original SIG-WSH proposal for harmonization. Can you please confirm if the plan for this TC has been changed? And if so why? Thx -- des 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 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) ? ? ? Identity Provider Service (IdPS) ? ? -----Original Message----- From: sig-wsh-bounces at lists.projectliberty.org [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Eve Maler Sent: Friday, November 21, 2008 11:08 AM To: sig-wsh at lists.projectliberty.org Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon Attending: Eve Maler, Brett McDowell, Kurt Kolok, John Bradley, Jonas Hogberg, Paul Madsen, Hubert Le Van Gong, Don Schmidt, George Fletcher Notes from last meeting: http://wiki.projectliberty.org/index.php/SIG-WSH_Aug_08_Redmond_F2F Note that 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 it 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: It's 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 (may leverage WS-Trust)? 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's 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! AI: Paul and John to put together a strawman for discussion at a follow-on focused SIG-WSH call about discovery/lookup. AI: John and the TEG reps to pursue focused inquiries with their communities about discovery/lookup harmonization. 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. AI: Eve to ask Brett for a timeline on when the LAP slides (or a facsimile) can be made public. Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. _______________________________________________ Sig-wsh mailing list Sig-wsh at lists.projectliberty.org http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmadsen at rogers.com Sun Nov 23 14:17:50 2008 From: paulmadsen at rogers.com (Paul Madsen) Date: Sun, 23 Nov 2008 17:17:50 -0500 Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon In-Reply-To: <97D5E1BB8FC13D4EA3B34BAE8E6898C92F53AB97@orsmsx508.amr.corp.intel.com> References: <2AE73F30-AD06-471C-BFF8-77A060FDD705@sun.com> <60BD80BD555E91479F996CCB05EB849816243E8AEF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <97D5E1BB8FC13D4EA3B34BAE8E6898C92F53AB97@orsmsx508.amr.corp.intel.com> Message-ID: <4929D68E.1040306@rogers.com> yes, the goal and intent is to profile WS-Trust. I expect this would be included in the charter paul Cahill, Conor P wrote: > > The plans haven?t changed in any substantial way. I think the ?may? > was inserted to indicate that it?s still possible that we could > **possibly** run into issues mapping features/functionality with the > current WS-Trust spec (e.g. the work isn?t done yet). If you look > later into the description under that item you can see ?Currently they > aren't defined as profiles of WS-Trust, but that's the intended > mechanism for them in future.? > > > > So it is intended to use WS-Trust (as we discussed at the SIG-WSH F2F). > > > > Conor > > > > *From:* sig-wsh-bounces at lists.projectliberty.org > [mailto:sig-wsh-bounces at lists.projectliberty.org] *On Behalf Of *Don > Schmidt > *Sent:* Sunday, November 23, 2008 1:20 PM > *To:* Eve Maler; sig-wsh at lists.projectliberty.org > *Subject:* Re: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon > > > > Eve, Bret > > > > I am confused by the highlighted comment after the second TC in the > mail below. > > 2. "IdM Services TC", to receive: > > - AS, SSOS, IMS, IDPS (may leverage WS-Trust)? > > > > It was my understanding that the harmonization of these WF specs with > WS-Trust was one of the two major goals of SIG-WSH. That was a > significant part of the first SIG-WSH face-face meeting discussions. > Conor explained in detail where there were obvious points for WSF > token issuing services to be revised to maximize re-use of WS-Trust. > This was captured in the WIKI minutes which I pasted in below for easy > reference. > > > > The highlighted annotation for this TC appears to indicate a > significant departure from the original SIG-WSH proposal for > harmonization. Can you please confirm if the plan for this TC has > been changed? And if so why? > > > > Thx -- des > > > > 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 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) > > ? ? > > ? Identity Provider Service (IdPS) > > ? ? > > > > > > -----Original Message----- > From: sig-wsh-bounces at lists.projectliberty.org > [mailto:sig-wsh-bounces at lists.projectliberty.org] On Behalf Of Eve Maler > Sent: Friday, November 21, 2008 11:08 AM > To: sig-wsh at lists.projectliberty.org > Subject: [Sig-wsh] Notes from 21 Nov 2008 SIG-WSH telecon > > > > Attending: Eve Maler, Brett McDowell, Kurt Kolok, John Bradley, Jonas > > Hogberg, Paul Madsen, Hubert Le Van Gong, Don Schmidt, George Fletcher > > > > Notes from last meeting: > http://wiki.projectliberty.org/index.php/SIG-WSH_Aug_08_Redmond_F2F > > > > Note that 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 it 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: It's > > 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 (may leverage WS-Trust)? > > > > 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's 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! > > > > AI: Paul and John to put together a strawman for discussion at a > > follow-on focused SIG-WSH call about discovery/lookup. > > AI: John and the TEG reps to pursue focused inquiries with their > > communities about discovery/lookup harmonization. > > > > 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. > > > > AI: Eve to ask Brett for a timeline on when the LAP slides (or a > > facsimile) can be made public. > > > > > > Eve Maler +1 425 947 4522 > > Principal Engineer eve.maler @ sun.com > > Business Alliances group Sun Microsystems, Inc. > > > > _______________________________________________ > > Sig-wsh mailing list > > Sig-wsh at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sig-wsh mailing list > Sig-wsh at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-wsh_lists.projectliberty.org > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.549 / Virus Database: 270.9.9/1807 - Release Date: 23/11/2008 10:59 AM > -- ConnectID -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gMwy.1.gif Type: image/gif Size: 8987 bytes Desc: not available URL: From Hubert.Levangong at Sun.COM Mon Nov 24 07:54:36 2008 From: Hubert.Levangong at Sun.COM (Hubert Le Van Gong) Date: Mon, 24 Nov 2008 16:54:36 +0100 Subject: [Sig-wsh] Fwd: Invitation to join the Metadata Discovery Coordination Group References: Message-ID: <10CA9915-2A37-42E3-9F94-B3ABB2CC0331@sun.com> Even though our primary purpose is the harmonization with the WS-* stack, this is interesting in light of our recent discussion on discovery. Hubert Begin forwarded message: > From: Eran Hammer-Lahav > Date: November 22, 2008 12:23:22 AM CEST > To: "specs at openid.net" , "general at openid.net" > > Subject: Invitation to join the Metadata Discovery Coordination Group > > Discussions about URI metadata discovery have been going on in many > places > for the past couple of years. This has been reaching its boiling > point with > the recent discussions between the W3C TAG, XRI TC, POWDER WG, the > OpenID / > Yadis, OAuth, Portable Contacts, XRDS-Simple, and OpenSocial > communities, > and various IETF I-Ds published on related topics. > > Web Discovery is likely to consist of two parts, the *retrieval* and > *format* of a metadata document linked to a resource identified by a > URI. > There are multiple proposals for the metadata document format, with > XRDS and > POWDER as two notable examples. Discussions regarding metadata > format should > and will remain where they are currently being held. > > However, there is great recognizable value in a single (simple) > mechanism > for *retrieval* of metadata for resources identified with a URI. > From the > most basic use case of identifying which API is supported by a given > endpoint, to a more complex trusted identity resolution, the > requirements > seems to be significantly overlapping. > > For many of these communities, time is running out and most are > getting > ready to put the final touches and ship specifications that already > have > running code. We have a rare (but narrow) opportunity to quickly go > through > the current proposals and at least set the tone for current and future > discovery solutions. > > I am not ignoring the political complications of trying to reach > consensus > among so many entities and communities but I truly believe from the > many > hours of conversations I had the past 2 months that we are mostly > all on the > same page. All I think we now need is a room, and hence this new list: > metadata-discovery at googlegroups.com. > > This is not a working group, nor does this group have any > deliverables or > will produce specifications. It is designed as a coordination venue > for the > various efforts going on to discuss their proposals and progress. It > is also > for soliciting feedback and confirming assumptions about discovery > proposals. > > Given the complexities behind IPR policies and the significant > differences, > this list does not have an IPR policy. This means that discussions > held here > are not covered, and if produce anything other than normative > references to > existing standards (which is clearly the intention), will need to be > resolved if adopted elsewhere. > > Web discovery has been my top priority for the past year and I am > excited to > finally reach the point where a critical mass is formed to finally > address > it. Please join the discussion at > http://groups.google.com/group/metadata-discovery. > > EHL > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs -- Hubert A. Le Van Gong Sun microsystems, Inc. Business Alliances - Chief Technologist's Office 17 Rue Duprey Grenoble, 38000 France -------------------------------------------------- email: hubert.levangong at sun.COM tel:+33 4 7663 0935 blog: http://blog.levangong.com/ N 45 12.011' W 005 44.217' -------------- next part -------------- An HTML attachment was scrubbed... URL: