From asa.openliberty at zenn.net Wed Feb 6 20:30:13 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Wed, 6 Feb 2008 23:30:13 -0500 Subject: [wsf-dev] ClientLib DEV Call Feb 7 2008 - 8am pacific In-Reply-To: <7BB11D91-9DE7-4309-8C0A-C34775D73300@zenn.net> References: <7BB11D91-9DE7-4309-8C0A-C34775D73300@zenn.net> Message-ID: Hi All, Please join me 8 A.M. Pacific / 11 A.M. Eastern Thursday Feb 7 for the bimonthly developer call. Deadline for the BETA is February 16th, lots of work still to do. Agenda: * ECP Firefox Plugin * BETA Deliverables * March TEG Plenary - Santa Clara - interop Call Options: US/Canada 866.411.0013, pin 0123586# Outside US/Canada 734.615.7474, pin 0123586# more options here: http://openliberty.org/wiki/index.php/Main_Page#Developer_Phone_Calls talk to you soon, asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 From santtu.toivonen at gmail.com Tue Feb 12 05:28:43 2008 From: santtu.toivonen at gmail.com (Santtu Toivonen) Date: Tue, 12 Feb 2008 15:28:43 +0200 Subject: [wsf-dev] CFP: Context Awareness and Trust 2008 (CAT 08) Message-ID: <5ed7921a0802120528l1a0a7fe8leffedff113f99751@mail.gmail.com> (* ---- please apologize for multiple copies ---- *) --- CALL FOR PAPERS --- * ********************************************************** * * Context Awareness and Trust 2008 (CAT 08) * * Second International Workshop on * * Combining Context with Trust, Security, and Privacy * * (16-17 June 2008) * http://cat08.telin.nl * * ---------------------------------------------------------- * * Co-located with IFIPTM2008, Joint iTrust and PST * * Conferences on Privacy, Trust Management and Security, * * Trondheim, Norway * * ********************************************************** * IMPORTANT DATES ---------------- Papers (abstract): 28th March 2008 Papers: 7th April 2008 Notification of Acceptance: 30th April 2008 Final version due: 23th May 2008 SCOPE --------------------- The CAT08 workshop aims to stimulate an active exchange of new ideas on interrelations between the area of context awareness and the area of security, privacy & trust. The workshop aims to bring together scientists and engineers that are active in the area of context awareness and in trust management, privacy and security. The workshop aims are to discuss state of the art, to identify open and emerging problems, to share research experiences, and to propose future research directions. We encourage not only researchers with a computer science background, but also researchers with a more user-centric background such as social sciences, behavioural science, and so on. WORKSHOP TOPICS -------------- Relevant topics, divided into three categories, include but are not limited to: ------------ 1. Context and Trust, Security and Privacy as an opportunity - Context-aware architectures for trust, security, and privacy - Enhancement of trust, security, and privacy with context information - Context-aware identity management and privacy enforcement - Formal Aspects in Context-aware trust, security, and privacy - Policy languages, ontologies for context-aware trust, security, and privacy - Market outlook for context-aware trust, security, and privacy ------------ 2. Context and Trust, Security and Privacy as a threat - Trust, security, and privacy of context and contextual data - Security and privacy in context-aware architectures - Trust, security, and privacy of context sources and information - User control over trust, security and privacy aspects of context-awareness - Context, Privacy, and Reputation ------------ 3. Context and Trust, Security and Privacy as application domains - Use cases and pilots addressing context-aware trust, security, and privacy - Usefulness and usability of context-aware trust, security, and privacy - Context-aware trust, privacy & security for the Semantic Web - Context-aware trust, privacy & security for social media - Social, legal, and philosophical aspects of context-aware trust - Context-depended reputations and recommendations PROGRAM COMMITTEE ------------------- Susana Alcalde University of Navarra, Spain Claudio Bettini University of Milano, Italy Harry Chen Image Matters LLC, USA Tyrone W. Grandison IBM Almaden Research, USA Victor S. Grishchenko Ural State University, Russia Heikki Helin TeliaSonera, Finland Mario Hoffmann Fraunhofer-Institute SIT, Germany Bob Hulsebosch Telematica Instituut, The Netherlands Ayman Kayssi American University of Beirut, Lebanon Anders Kofod-Petersen NTNU, Norway Gabriele Lenzini Telematica Instituut, The Netherlands Giannis F. Marias University of Athens, Greece Daniel Olmedilla L3S Research Center and University of Hannover, Germany Daniele Quercia University College London, United Kingdom Bart van Rijnsoever Philips Research, The Netherlands Philip Robinson SAP Research, United Kingdom Jean-Marc Seigneur University of Geneva and Venyo, Switzerland Santtu Toivonen Idean Enterprises, Finland Maarten Wegdam University of Twente, The Netherlands Zheng Yan Nokia Research Center, Finland INVITED SPEAKERS ---------------- We are planning to have an invited speaker. Please visit our web site. SPONSORS AND ACKNWOLEDGEMENT ---------------------------- The organizers are supported by University of Geneva and Venyo, Telematica Instituut, and Idean Enterprises. PAPER SUBMISSION ---------------- Theoretical and applied research papers are welcome. - Full papers (limited to 12 pages) describe high-quality original unpublished research, case studies, and implementation experiences. - Short papers (limited to 4 pages) describe either work-in-progress on ongoing research or properly motivated future research. Please visit CAT08 web page to read submission conditions and guideline. PROCEEDINGS ----------- A preprint version of the proceedings will available at the workshop. Accepted papers will be published in a post-workshop proceedings. REGISTRATION ------------ At least one author of each paper is expected to register and to present the paper at the workshop. Those papers that, without motivation, are not presented at the workshop will be excluded by the proceedings. ORGANIZING COMMITTEE ------------------- - Bob Hulsebosch Telematica Instituut, The Netherlands - Gabriele Lenzini Telematica Instituut, The Netherlands - Jean-Marc Seigneur University of Geneva and Venyo, Switzerland - Santtu Toivonen Idean Enterprises, Finland CONTACT ------- For more information please visit out web site http://cat08.telin.nl From asa.openliberty at zenn.net Fri Feb 15 13:44:08 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Fri, 15 Feb 2008 16:44:08 -0500 Subject: [wsf-dev] signing questions Message-ID: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> Hi All, I am now able to sign outgoing messages. And I have some questions for the experts on the list. 1. Messages over TLS carrying a SAMLv2 token: - is this considered urn:liberty:security:2005-02:TLS:Bearer or urn:liberty:security: 2005-02:TLS:SAMLV2 2. It appears that the "authentication mechanisms" listed do not have any reference to signed or unsigned. Is this true? How is the requirement of signing communicated between server/client? 3. When are signed messages generally used in WSF? Can it begin with the first SASL request to the AS? 4. Is meta-data exchange completely out of the ID-WSF band? 5. Are responses from the WSP signed as well? In which case I need the public key from the WSP. 6. My signature references the Body, and all of the header elements. Why not sign the SOAP envelope and call it a day? Is this because portions may be passed on to another end point? 7. Does a signed message require an x.509 token? many thanks, asa From conor.p.cahill at intel.com Fri Feb 15 14:01:13 2008 From: conor.p.cahill at intel.com (Cahill, Conor P) Date: Fri, 15 Feb 2008 14:01:13 -0800 Subject: [wsf-dev] signing questions In-Reply-To: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> Message-ID: <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> > 1. Messages over TLS carrying a SAMLv2 token: - is this considered > urn:liberty:security:2005-02:TLS:Bearer or urn:liberty:security: > 2005-02:TLS:SAMLV2 The ...:SAMLV2 method requires a signature on the message. The ...:Bearer method does not. So just sticking a SAML token on a message without signing the message is ...:Bearer. > 2. It appears that the "authentication mechanisms" listed do not have > any reference to signed or unsigned. Is this true? How is the > requirement of signing communicated between server/client? As outlined above. > 3. When are signed messages generally used in WSF? Can it begin > with the first SASL request to the AS? Signed messages can be used anywhere. In many cases, the SASL messages to the AS are unsigned, but that is just what people have done rather than a rule or expectation. The EPR for the service provider (AS, DS, PS, etc.) will define the security mechanism which will define whether or not signing is required. > 4. Is meta-data exchange completely out of the ID-WSF band? The DS is the primary means of metadata exchange for ID-WSF messages, though it isn't required (so you can have some ID-WSF environments where the service EPR is distributed via some other means -- such as the DS EPR showing up in a SAML SSO assertion or when a client has a built-in EPR for the AS). The EPR is the primary Metadata container for ID-WSF invocations. > 5. Are responses from the WSP signed as well? In which case I need > the public key from the WSP. They can be. There's a DS option that can be used in service metadata to define when a WSP signs responses (and can be a factor in DS queries). This is covered in section 3.11 of the Disco spec. > 6. My signature references the Body, and all of the header elements. > Why not sign the SOAP envelope and call it a day? Is this because > portions may be passed on to another end point? It's part of the WS-Security model because other headers can be added/removed as the message is sent through other parties. Not all header elements are required to be signed (all Liberty headers are required to be signed, but there can be other headers that aren't necessarily signed. I believe that the WS-Security header itself isn't signed as the signature itself is added to that element. > 7. Does a signed message require an x.509 token? No. Signatures can be based upon any of the xmldsig supported models. Of course basic public/private keys (which aren't x.590 tokens) can be used, but you can also use shared secret signatures. Conor From asa.openliberty at zenn.net Fri Feb 15 14:09:03 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Fri, 15 Feb 2008 17:09:03 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> Message-ID: <4E3FBAEE-4FA5-4DA5-A696-0F516E52FDE2@zenn.net> Conor: You rock! Thanks for the answers, clarifies a lot. asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 On Feb 15, 2008, at 5:01 PM, Cahill, Conor P wrote: > >> 1. Messages over TLS carrying a SAMLv2 token: - is this considered >> urn:liberty:security:2005-02:TLS:Bearer or urn:liberty:security: >> 2005-02:TLS:SAMLV2 > > The ...:SAMLV2 method requires a signature on the message. The > ...:Bearer method does not. So just sticking a SAML token on a > message without signing the message is ...:Bearer. > >> 2. It appears that the "authentication mechanisms" listed do not have >> any reference to signed or unsigned. Is this true? How is the >> requirement of signing communicated between server/client? > > As outlined above. > >> 3. When are signed messages generally used in WSF? Can it begin >> with the first SASL request to the AS? > > Signed messages can be used anywhere. In many cases, the SASL > messages > to the AS are unsigned, but that is just what people have done rather > than a rule or expectation. > > The EPR for the service provider (AS, DS, PS, etc.) will define the > security mechanism which will define whether or not signing is > required. > >> 4. Is meta-data exchange completely out of the ID-WSF band? > > The DS is the primary means of metadata exchange for ID-WSF messages, > though it isn't required (so you can have some ID-WSF environments > where the service EPR is distributed via some other means -- such > as the DS EPR showing up in a SAML SSO assertion or when a client > has a built-in EPR for the AS). > > The EPR is the primary Metadata container for ID-WSF invocations. > >> 5. Are responses from the WSP signed as well? In which case I need >> the public key from the WSP. > > They can be. There's a DS option that can be used in service metadata > to define when a WSP signs responses (and can be a factor in DS > queries). > This is covered in section 3.11 of the Disco spec. > >> 6. My signature references the Body, and all of the header elements. >> Why not sign the SOAP envelope and call it a day? Is this because >> portions may be passed on to another end point? > > It's part of the WS-Security model because other headers can be > added/removed as the message is sent through other parties. Not > all header elements are required to be signed (all Liberty headers > are required to be signed, but there can be other headers that > aren't necessarily signed. I believe that the WS-Security header > itself > isn't signed as the signature itself is added to that element. > >> 7. Does a signed message require an x.509 token? > > No. Signatures can be based upon any of the xmldsig supported > models. > Of course basic public/private keys (which aren't x.590 tokens) can > be used, but you can also use shared secret signatures. > > Conor > From cantor.2 at osu.edu Fri Feb 15 15:22:27 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Fri, 15 Feb 2008 18:22:27 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> Message-ID: <011001c87029$a1267000$e3735000$@2@osu.edu> > > 1. Messages over TLS carrying a SAMLv2 token: - is this considered > > urn:liberty:security:2005-02:TLS:Bearer or urn:liberty:security: > > 2005-02:TLS:SAMLV2 > > The ...:SAMLV2 method requires a signature on the message. The > ...:Bearer method does not. So just sticking a SAML token on a > message without signing the message is ...:Bearer. It also depends on how you "sign". The TLS:SAMLV2 method means TLS + a SAML assertion + a signature, I think. The TLS:peerSAMLV2 method would be TLS + SAML assertion and that's it. Still "signed" but with TLS. (Point being the exact mech depends on whether you sign the message, not just whether it's TLS + a SAML token.) > The EPR is the primary Metadata container for ID-WSF invocations. Yes, but that metadata doesn't include the key (pun intended) piece of metadata, the KeyDescriptors. SAML metadata can be used to establish the trust layer. > aren't necessarily signed. I believe that the WS-Security header itself > isn't signed as the signature itself is added to that element. It is. The Reference to that header has an enveloped transform in it to exclude the Signature. > > 7. Does a signed message require an x.509 token? > > No. Signatures can be based upon any of the xmldsig supported models. > Of course basic public/private keys (which aren't x.590 tokens) can > be used, but you can also use shared secret signatures. There's also the fact that the message doesn't have to include the certificate. Usually does, but that's a hint. -- Scott From cantor.2 at osu.edu Fri Feb 15 15:32:16 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Fri, 15 Feb 2008 18:32:16 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <011001c87029$a1267000$e3735000$%2@osu.edu> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> Message-ID: <011601c8702b$00366a90$00a33fb0$@2@osu.edu> > Yes, but that metadata doesn't include the key (pun intended) piece of > metadata, the KeyDescriptors. SAML metadata can be used to establish the > trust layer. Clarifying, I didn't mean the trust between the WSC and the WSP, the IdP/DS/whatever can broker that part through the tokens themselves. -- Scott From asa.openliberty at zenn.net Fri Feb 15 15:48:38 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Fri, 15 Feb 2008 18:48:38 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <011001c87029$a1267000$e3735000$@2@osu.edu> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$@2@osu.edu> Message-ID: <8CD25CC2-C8B1-48D0-B2F7-D4FF07F2732F@zenn.net> Ah. > It also depends on how you "sign". The TLS:SAMLV2 method means TLS + > a SAML > assertion + a signature, I think. this makes sense. It seems that according to the idwsf-sec-mech core v2 (6.3.4 line 595) I need to include a ds:KeyInfo to describe the key needed to validate the signature, unless I am using peer (see below) > The TLS:peerSAMLV2 method would be TLS + SAML assertion and that's > it. Still > "signed" but with TLS. Peer means that the message contains a signature that uses the same keys that the TLS layer is using, right? Or am I not understanding this correctly? >> The EPR is the primary Metadata container for ID-WSF invocations. > > Yes, but that metadata doesn't include the key (pun intended) piece of > metadata, the KeyDescriptors. SAML metadata can be used to establish > the > trust layer. I like the pun ;) - basically though, I either need to include the public key in the message, or a reference to that public key so that the result of the signature can be validated, right? > There's also the fact that the message doesn't have to include the > certificate. Usually does, but that's a hint. By usually does, you mean that the public key is usually included in the KeyInfo? By hint do you mean a reference to the key? thanks, asa From asa.openliberty at zenn.net Fri Feb 15 15:50:20 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Fri, 15 Feb 2008 18:50:20 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <011601c8702b$00366a90$00a33fb0$%2@osu.edu> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> <011601c8702b$00366a90$00a33fb0$%2@osu.edu> Message-ID: <6F5E607A-26A6-40A8-8A7B-EFC60DBE0BD4@zenn.net> That is a relief! :) asa On Feb 15, 2008, at 6:32 PM, Scott Cantor wrote: >> Yes, but that metadata doesn't include the key (pun intended) piece >> of >> metadata, the KeyDescriptors. SAML metadata can be used to >> establish the >> trust layer. > > Clarifying, I didn't mean the trust between the WSC and the WSP, the > IdP/DS/whatever can broker that part through the tokens themselves. > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 From cantor.2 at osu.edu Fri Feb 15 16:26:37 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Fri, 15 Feb 2008 19:26:37 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <8CD25CC2-C8B1-48D0-B2F7-D4FF07F2732F@zenn.net> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> <8CD25CC2-C8B1-48D0-B2F7-D4FF07F2732F@zenn.net> Message-ID: <011e01c87032$980ccab0$c8266010$@2@osu.edu> > > The TLS:peerSAMLV2 method would be TLS + SAML assertion and that's > > it. Still "signed" but with TLS. > > Peer means that the message contains a signature that uses the same > keys that the TLS layer is using, right? Or am I not understanding > this correctly? No, peer means the key used at the transport layer is the one referenced by the assertion and thus satisfies the confirmation method. There is no XML signature over the message. > I like the pun ;) - basically though, I either need to include the > public key in the message, or a reference to that public key so that > the result of the signature can be validated, right? When you sign something, it's out of scope how the relying party does anything to validate the signature. It is common to include the key or certificate. With some models, the relying party might already have the key, so including it is fine, but not always necessary. In this case, things are more complex. The assertion is what actually identifies the key you're supposed to use. The one in the Security header would actually be redundant, since it has to be the same key. That doesn't mean you shouldn't put it there, but all roads lead to the same place anyway. (Of course that assumes a SAML token is used. If you're just signing with a key and relying on some other mechanism for the RP to trust your key, then you certainly would normally put it in the signature.) > By usually does, you mean that the public key is usually included in > the KeyInfo? By hint do you mean a reference to the key? Yes, it's usually included, typically as a certificate (which both helps and confuses matters). No, I mean that KeyInfo is ALWAYS a hint. Whether it's a reference or not, the RP MUST verify separately that the key used to sign "belongs" to the signer. KeyInfo cannot do that for you. It's merely a way to shortcut things so that you don't have to try the wrong keys. In a model where a SAML HoK assertion is used, the assertion issuer is what provides that proof of ownership to you, by embedding the key inside the assertion. That allows a RP to decide that the signer is allowed to act as the assertion's subject by virtue of trusting the issuer. Of course, that trust is based on (ta da) the Signature in the assertion, and binding that key to the issuer (rinse, repeat). The problem is that you still have to compare the key inside the assertion with the key used by the message signer. That's relatively easy if the key is included by value, of course, it's simple math (or can be). But it's much harder if references are used instead because that brings in the entire notion of PKI. All of this stuff is left out of scope. Which would be fine if the whole system didn't depend on it. The reams of code you're seeing in OpenSAML et al. are mostly about this whole problem. The WSF mechs simplify the task of the WSC, but the WSP still needs to do all this verification stuff, eventually chaining back to the SAML layer, which is where my metadata comment came in. If you're focused on the WSC side, things are much cleaner. Until you want to verify the TLS key or signature of the WSP anyway... -- Scott From cantor.2 at osu.edu Fri Feb 15 16:32:31 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Fri, 15 Feb 2008 19:32:31 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <011001c87029$a1267000$e3735000$%2@osu.edu> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> Message-ID: <012001c87033$6ab72690$402573b0$@2@osu.edu> > > aren't necessarily signed. I believe that the WS-Security header itself > > isn't signed as the signature itself is added to that element. > > It is. The Reference to that header has an enveloped transform in it to > exclude the Signature. Sorry for the error, as you noted on the other list, it's usually just pointing at children inside the header, not signing the actual header. (It could sign it, but that would limit the mutability of the header. Which is irrelevant in 99% of the cases, but that's just how it's done.) -- Scott From asa.openliberty at zenn.net Fri Feb 15 17:28:06 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Fri, 15 Feb 2008 20:28:06 -0500 Subject: [wsf-dev] signing questions In-Reply-To: <011e01c87032$980ccab0$c8266010$%2@osu.edu> References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> <8CD25CC2-C8B1-48D0-B2F7-D4FF07F2732F@zenn.net> <011e01c87032$980ccab0$c8266010$%2@osu.edu> Message-ID: Wow. Not confusing in the least!! > No, peer means the key used at the transport layer is the one > referenced by > the assertion and thus satisfies the confirmation method. There is > no XML > signature over the message. ok. Given a WSC "c" and a WSP "p". For Peer, there must be ClientTLS established, meaning mutual TLS. This requires that both c and p have private keys. Does p tell c to use a specific private key that c has and p knows about? > When you sign something, it's out of scope how the relying party does > anything to validate the signature. It is common to include the key or > certificate. With some models, the relying party might already have > the key, > so including it is fine, but not always necessary. check. > In this case, things are more complex. The assertion is what actually > identifies the key you're supposed to use. The one in the Security > header > would actually be redundant, since it has to be the same key. That > doesn't > mean you shouldn't put it there, but all roads lead to the same place > anyway. ugg.. So as a WSC, the SAML Assertion given to me would specify that I use a specific private key for the TLS? > (Of course that assumes a SAML token is used. If you're just signing > with a > key and relying on some other mechanism for the RP to trust your > key, then > you certainly would normally put it in the signature.) I see. So what I am currently doing, which is signing an outgoing message with my very own key, paying no heed to the SAML Assertion, would be acceptable, but has no relationship to the TLS:SAMLV2 sech mech. Rather it is signed TLS:Bearer with the Bearer Token being a SAML assertion. I am relying on the party that I am communicating with to already trust me (and trust that I've kept my key safe and not checked it in to an open source svn repo) and have my public key available. > >> By usually does, you mean that the public key is usually included in >> the KeyInfo? By hint do you mean a reference to the key? > > Yes, it's usually included, typically as a certificate (which both > helps and > confuses matters). > > No, I mean that KeyInfo is ALWAYS a hint. Whether it's a reference > or not, > the RP MUST verify separately that the key used to sign "belongs" to > the > signer. KeyInfo cannot do that for you. It's merely a way to > shortcut things > so that you don't have to try the wrong keys. I get it now. So this could potentially save a high traffic end point a great deal of pain by hinting at the proper cert. > In a model where a SAML HoK assertion is used, the assertion issuer > is what > provides that proof of ownership to you, by embedding the key inside > the > assertion. That allows a RP to decide that the signer is allowed to > act as > the assertion's subject by virtue of trusting the issuer. Of course, > that > trust is based on (ta da) the Signature in the assertion, and > binding that > key to the issuer (rinse, repeat). Ok. So as a WSC the following process might take place. 1. SAML Authority issues a HoK Assertion to the WSC (through some auth process). The WSP has a trust relationship with the SAML Authority 2. WSC signs a request with its private key and sends request to WSP over SSL (using the WSPs cert). WSP already has or is supplied with the WSCs public key 3. WSP signs message with its private key and sends response encrypted with the key provided in the HoK Assertion. WSC already has the server's public key. How does the WSC decrypt the response? Step 3 is a little fuzzy to me. > If you're focused on the WSC side, things are much cleaner. Until > you want > to verify the TLS key or signature of the WSP anyway... So as a WSC my life is relatively simple, unless I want to do verification of a WSPs responses. asa From cantor.2 at osu.edu Fri Feb 15 18:20:48 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Fri, 15 Feb 2008 21:20:48 -0500 Subject: [wsf-dev] signing questions In-Reply-To: References: <58D13874-845E-42C3-AE79-3F1082157817@zenn.net> <1B47D24854C7BC4FA8DA28BEBB59B0BA02FE94D0@orsmsx419.amr.corp.intel.com> <011001c87029$a1267000$e3735000$%2@osu.edu> <8CD25CC2-C8B1-48D0-B2F7-D4FF07F2732F@zenn.net> <011e01c87032$980ccab0$c8266010$%2@osu.edu> Message-ID: <012101c87042$8b9ec610$a2dc5230$@2@osu.edu> > Wow. Not confusing in the least!! Kerberos and symmetric keys have their appeal. > ok. Given a WSC "c" and a WSP "p". For Peer, there must be > ClientTLS established, meaning mutual TLS. This requires that both c > and p have private keys. Does p tell c to use a specific private key > that c has and p knows about? I couldn't tell you for certain, I think it probably depends on the exact mechanism. In a pure TLS model with no assertion involved, it's often implicit what key to use. I don't know if the EPR can actually identify the key. (I would think it could, Conor would know. But my bet is it wouldn't normally.) In a SAML HoK + ClientTLS model, it's obviously possible to identify the key from the confirmation data. (That doesn't mean the WSC is looking at it, just that it could.) The SAML + ClientTLS model is not any different in terms of these issues from the SAML + Signing model. Initiating TLS with a key vs. signing with a key is not really that different, at least conceptually. > ugg.. So as a WSC, the SAML Assertion given to me would specify that I > use a specific private key for the TLS? Or for signing, same issue. It does in some fashion, because it has to tell the RP (WSP) which key had to be used to satisfy HoK. The trick is that KeyInfo is wide open so there's no rule saying *how* it tells the RP that. Whether the WSC is looking at that also is an implementation issue. I know from past conversations that many implementers wouldn't, they prefer to remain ignorant of the token. It seems to me that implies you have to guess (or just know) the key to use. That's a nice theory, but in practice the use of PKI all over tends to lead to deployments wielding multiple certificates, sometimes with different keys. That may or may not imply that the WSC ends up having to look at the assertion. We have layers of code responsible for mapping a KeyInfo into the credential store(s) to find the right key. This is one place I would use it, and another is for decryption (the sender tells me which of my keys he used to encrypt the bulk encryption key under). > I see. So what I am currently doing, which is signing an outgoing > message with my very own key, paying no heed to the SAML Assertion, > would be acceptable, but has no relationship to the TLS:SAMLV2 sech > mech. Well, no. If the assertion is HoK, then you MUST sign and you'd better guess right about which key to sign with. And the SAMLV2 mech in Liberty implies HoK, that's part of the profile. Bearer implies, well, Bearer. And to correct myself again (ok, my original message was a winner, too much caffeine)...I forgot that the second to last field can be TLS or ClientTLS. TLS alone just means server side TLS. So the one I was trying to point out in that original note was ClientTLS:peerSAMLV2. I felt it needed to be mentioned because I don't think much of XML Signature, and I think ClientTLS is often a much more reliable means of addressing that requirement. Summing up (corrections welcome and no doubt forthcoming): TLS:SAMLV2 means the server uses TLS, the client signs and has a HoK assertion. TLS:Bearer means the server uses TLS, the client just attaches a Bearer assertion. ClientTLS:Bearer combines mutual TLS with a Bearer assertion, giving you some additional flexibility to identify a user in the token. ClientTLS:peerSAMLV2 is where you do mutual TLS, have a HoK assertion, but don't sign. The edge case is ClientTLS:SAMLV2, which is an outlier. > Rather it is signed TLS:Bearer with the Bearer Token being a > SAML assertion. See above. That wouldn't have to involve you signing. It *could* if you wanted to, but isn't part of the assumed behavior in the spec. > I am relying on the party that I am communicating > with to already trust me (and trust that I've kept my key safe and not > checked it in to an open source svn repo) and have my public key > available. Any place you're not using a SAML HoK token to "broker" your key, then the trust model in use between you and the WSP for any use of a key by the WSC is out of scope. Necessary, just not specified. > I get it now. So this could potentially save a high traffic end point > a great deal of pain by hinting at the proper cert. That's the idea, yeah. You don't want to waste time doing RSA math using the wrong key. If you can guess right, you can handle things like key rollover where you run with two keys for a time without hurting performance. The point of all this I'm saying is that you can talk all day about the "normal" way to do all this stuff with KeyInfo, but at the end of the day, nothing requires it. The challenge is decoding how far to go handling all the options. Some of them are just plain stupid, IMNSHO, and others have reasonable justifications. > 1. SAML Authority issues a HoK Assertion to the WSC (through some auth > process). The WSP has a trust relationship with the SAML Authority > > 2. WSC signs a request with its private key and sends request to WSP > over SSL (using the WSPs cert). WSP already has or is supplied with > the WSCs public key In a HoK case, the WSP doesn't need the WSC's key in advance (or even any way to trust it directly). > 3. WSP signs message with its private key and sends response encrypted > with the key provided in the HoK Assertion. WSC already has the > server's public key. Well, you're saying TLS/SSL, so in that case I doubt the WSP would encrypt its response, the channel handles that for you. If it did encrypt, yeah, it could certainly do it with that key from the assertion, it's being told that the requester owns that key. > How does the WSC decrypt the response? Step 3 is a little fuzzy to me. Because it isn't really typical. If you took out the SSL though, sure, you could encrypt the messages with XML. You're asking about the mechanics of that, that's a whole other thread. In brief, with a PK model, you randomly generate a symmetric key for the encryption, then you encrypt/wrap *that* key with the recipient's public key. The WSC would decrypt the encryption key with its private key and then decrypt the data. (And oh yeah, all those decrypt steps involve KeyInfo to identify *your* key to use to decrypt with.) > So as a WSC my life is relatively simple, unless I want to do > verification of a WSPs responses. Yes, this is by design in ID-WSF. (I'd note that it isn't as simple when you wield multiple keys and certs though.) And I realize that's what you were asking about, but the full stack has to deal with the whole picture. It's important to understand it (even if it takes me three tries to correct my own mistakes and undoubtedly more input from others to correct many more). -- Scott From asa.openliberty at zenn.net Tue Feb 19 17:17:27 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Tue, 19 Feb 2008 20:17:27 -0500 Subject: [wsf-dev] CredentialsContext / samlp:RequestedAuthnContext Message-ID: <4F5C7EC3-77C6-4E28-919B-E9E5949DAC6A@zenn.net> Hi All, I am now digging in to handling the CredentialsContext header element of an ID-* message. There are two basic things that can be sent: * 0 or more SecurityMechanismIDs, indicating appropriate security mechanisms for further requests * a saml2 RequestedAuthnContext In the case of the sec mech ids, I can think of several options, possibly the best is making another discovery request specifying the first sech mech and the current provider id, and then down the line of listed sech mechs until I get an epr that satisfies the requirement. In the case of a RequestedAuthnContext, what the heck do I do? From the docs: 1263 The receiver of a header containing a RequestAuthnContext element SHOULD use 1264 credentials that conform to the policies specified therein in any future requests to the sender of this header (where 1265 credentials are required). thanks, asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080219/95d0f915/attachment.html From cantor.2 at osu.edu Tue Feb 19 17:59:09 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Tue, 19 Feb 2008 20:59:09 -0500 Subject: [wsf-dev] CredentialsContext / samlp:RequestedAuthnContext In-Reply-To: <4F5C7EC3-77C6-4E28-919B-E9E5949DAC6A@zenn.net> References: <4F5C7EC3-77C6-4E28-919B-E9E5949DAC6A@zenn.net> Message-ID: <019101c87364$2edbf4f0$8c93ded0$@2@osu.edu> > In the case of a RequestedAuthnContext, what the heck do I do? IIRC, the assumption was that it would be sent as input when contacting an AS or SSOS for credentials. I think in the AS case there's someplace you're supposed to be able to supply it as part of negotiating the SASL mech. In the SSOS case you'd put it in your AuthnRequest. -- Scott From asa.openliberty at zenn.net Mon Feb 25 08:39:04 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Mon, 25 Feb 2008 11:39:04 -0500 Subject: [wsf-dev] naming? Message-ID: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> Hi all, I am working on getting the documentation up, a blog post, and a slight site restructuring, but: The BETA Code is available!! Also, I think "ID-WSF 2.0 ClientLib" is a bit dry for an open source project name, do any of you have ideas for a name or naming? gracias, asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 From cantor.2 at osu.edu Mon Feb 25 10:45:49 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Mon, 25 Feb 2008 13:45:49 -0500 Subject: [wsf-dev] naming? In-Reply-To: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> Message-ID: <048001c877de$a43b8bb0$ecb2a310$@2@osu.edu> > Also, I think "ID-WSF 2.0 ClientLib" is a bit dry for an open source > project name, do any of you have ideas for a name or naming? Well, we went through this before and were unable to agree on anything very profound. I wasn't too happy with the choice, but I doubt any opinions have changed much. The main problem, IIRC, was an inability to use the term openLiberty as part of the name for some reason... -- Scott From brett at projectliberty.org Mon Feb 25 10:48:24 2008 From: brett at projectliberty.org (Brett McDowell) Date: Mon, 25 Feb 2008 13:48:24 -0500 Subject: [wsf-dev] naming? In-Reply-To: <-8098376148395210412@unknownmsgid> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> Message-ID: The only reason I can think of to not use openLiberty in the name might be our longer-term goal of getting these projects into the Apache Software Foundation. Otherwise I don't know why we couldn't use openLiberty in the name. On Mon, Feb 25, 2008 at 1:45 PM, Scott Cantor wrote: > > Also, I think "ID-WSF 2.0 ClientLib" is a bit dry for an open source > > project name, do any of you have ideas for a name or naming? > > Well, we went through this before and were unable to agree on anything > very > profound. > > I wasn't too happy with the choice, but I doubt any opinions have changed > much. The main problem, IIRC, was an inability to use the term openLiberty > as part of the name for some reason... > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org > -- Brett McDowell, +1-413-652-1248, www.projectliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080225/84b860e4/attachment-0001.html From cantor.2 at osu.edu Mon Feb 25 10:53:21 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Mon, 25 Feb 2008 13:53:21 -0500 Subject: [wsf-dev] naming? In-Reply-To: References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> Message-ID: <048801c877df$b40073c0$1c015b40$@2@osu.edu> > The only reason I can think of to not use openLiberty in the name might be > our longer-term goal of getting these projects into the Apache Software > Foundation. Otherwise I don't know why we couldn't use openLiberty in the > name. My recollection was that it was something to do with keeping the overall name disconnected from any specific deliverable, or something like that. Personally, I would simplify things by casting all this work as OpenLiberty-J and just nailing down the specific supported features (WSF client, server, etc) in the docs. But I argued for that originally and it didn't win, so... -- Scott From asa.openliberty at zenn.net Mon Feb 25 18:29:55 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Mon, 25 Feb 2008 21:29:55 -0500 Subject: [wsf-dev] =?iso-8859-1?q?=A1=A1beta_released!!?= Message-ID: <3D017A61-AE4A-4D7B-BAB9-EF23DD7D83D8@zenn.net> Hi All, The beta of the ClientLib is now available online. I also made some changes to the website, including some sample code. Here is the post: http://www.openliberty.org/blog/2008/02/25/beta/ talk later, asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 From brett at projectliberty.org Tue Feb 26 06:51:51 2008 From: brett at projectliberty.org (Brett McDowell) Date: Tue, 26 Feb 2008 09:51:51 -0500 Subject: [wsf-dev] naming? In-Reply-To: <4647544322378513577@unknownmsgid> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> Message-ID: Did you literally mean "openLiberty-J" or is "-J" a placeholder for a name for this subproject TBD? On Mon, Feb 25, 2008 at 1:53 PM, Scott Cantor wrote: > > The only reason I can think of to not use openLiberty in the name might > be > > our longer-term goal of getting these projects into the Apache Software > > Foundation. Otherwise I don't know why we couldn't use openLiberty in > the > > name. > > My recollection was that it was something to do with keeping the overall > name disconnected from any specific deliverable, or something like that. > > Personally, I would simplify things by casting all this work as > OpenLiberty-J and just nailing down the specific supported features (WSF > client, server, etc) in the docs. But I argued for that originally and it > didn't win, so... > > -- Scott > > > -- Brett McDowell, +1-413-652-1248, www.projectliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080226/1bd33dfa/attachment.html From cantor.2 at osu.edu Tue Feb 26 08:17:12 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Tue, 26 Feb 2008 11:17:12 -0500 Subject: [wsf-dev] naming? In-Reply-To: References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> Message-ID: <051101c87893$0b587010$22095030$@2@osu.edu> > Did you literally mean "openLiberty-J" or is "-J" a placeholder for a name > for this subproject TBD? No, I mean literally. Xerces is split into Xerces-J and Xerces-C, for example, as is OpenSAML (because I copied it). Basically, I don't think deployers out there understand or care about any distinctions inside ID-WSF. If they're at all interested, they'll expect the package to include it all and just need to know what's actually implemented inside the release notes. In Java, in particular, you only load classes that you use, so it doesn't matter how much you bundle into one. -- Scott From conor.p.cahill at intel.com Tue Feb 26 08:22:06 2008 From: conor.p.cahill at intel.com (Cahill, Conor P) Date: Tue, 26 Feb 2008 08:22:06 -0800 Subject: [wsf-dev] naming? In-Reply-To: <051101c87893$0b587010$22095030$@2@osu.edu> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net><-8098376148395210412@unknownmsgid><4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$@2@osu.edu> Message-ID: <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> I was trying to stay out of the discussion on naming... really, really trying... I think it is worthwhile differentiating between a client and a server implementation when we talk about the stuff. So perhaps OpenLiberty-J-Client or something that indicates it's the client side of Liberty in Java. Conor > -----Original Message----- > From: wsf-dev-bounces at lists.openliberty.org [mailto:wsf-dev- > bounces at lists.openliberty.org] On Behalf Of Scott Cantor > Sent: Tuesday, February 26, 2008 11:17 AM > To: 'Brett McDowell' > Cc: wsf-dev at openliberty.org > Subject: Re: [wsf-dev] naming? > > > Did you literally mean "openLiberty-J" or is "-J" a placeholder for a > name > > for this subproject TBD? > > No, I mean literally. Xerces is split into Xerces-J and Xerces-C, for > example, as is OpenSAML (because I copied it). > > Basically, I don't think deployers out there understand or care about any > distinctions inside ID-WSF. If they're at all interested, they'll expect > the > package to include it all and just need to know what's actually > implemented > inside the release notes. > > In Java, in particular, you only load classes that you use, so it doesn't > matter how much you bundle into one. > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf- > dev_lists.openliberty.org From cantor.2 at osu.edu Tue Feb 26 08:46:50 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Tue, 26 Feb 2008 11:46:50 -0500 Subject: [wsf-dev] naming? In-Reply-To: <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> Message-ID: <052c01c87897$2f7d1320$8e773960$@2@osu.edu> > I think it is worthwhile differentiating between a client and a server > implementation when we talk about the stuff. So perhaps OpenLiberty-J-Client or > something that indicates it's the client side of Liberty in Java. And we rejected that because to most people client means something they run on their desktop. So I've said my peace (again)...I think it should be one name, and don't agree with splitting client and server. -- Scott From asa.openliberty at zenn.net Tue Feb 26 10:14:19 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Tue, 26 Feb 2008 13:14:19 -0500 Subject: [wsf-dev] naming? In-Reply-To: <052c01c87897$2f7d1320$8e773960$%2@osu.edu> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> Message-ID: <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> I see where Conor is coming from and where Scott is coming from. OpenLiberty-J sounds good, I also like the uppercase "O" -- makes it look stronger. The differentiation between wsc and wsp is important, however, as we have discussed many times before, the lines are very blurry. The tooling that we have done for WSC would be re- useable for a WSP. The only problem is that openLiberty covers more than ID-WSF at then moment. Maybe that should change. OpenLiberty could still be the location of the work until the projects are under the apache foundation (kind of like the apache foundation itself -- apache is a webserver and a foundation) > OpenLiberty-J would be the java implementations of the ID-WSF specifications The package structure would determine the use (as it does now): org.openliberty.wsc -- where the wsc code currently exists org.openliberty.xmltooling -- where the base package for all of the java objects that represent the xml elements of the spec currently exist, eg, org.openliberty.xmltooling.disco org.openliberty.wsp -- base packagewhere WSP code might be On the level of documentation, creating clear segregation between client and server is critical. I imagine this would be done with use case sample code. Ideally we could get identity into the name in some way, and web services for that matter. And it should be catchy. OpenLiberty-J is catchy. Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: idSTAR-J IDStar-J OpenLID-J OpenLIDStar-J LibertyStar-J OpenLID*-J later, asa On Feb 26, 2008, at 11:46 AM, Scott Cantor wrote: >> I think it is worthwhile differentiating between a client and a >> server >> implementation when we talk about the stuff. So perhaps > OpenLiberty-J-Client or >> something that indicates it's the client side of Liberty in Java. > > And we rejected that because to most people client means something > they run > on their desktop. > > So I've said my peace (again)...I think it should be one name, and > don't > agree with splitting client and server. > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7 From curtis at upto11.com Tue Feb 26 10:26:25 2008 From: curtis at upto11.com (Curtis Jones) Date: Tue, 26 Feb 2008 13:26:25 -0500 Subject: [wsf-dev] naming? In-Reply-To: <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> Message-ID: <70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> I vote for "OpenLID" -- catchy, and has lots of marketing possibilities. The only downside is that it's pretty damn close to "OpenID" -- but it wouldn't be the first such set of similarly named libraries in the same space (e.g., TAPI vs TSAPI). I'd personally keep it simple/clean and leave off the "-J" except for actual package names or part numbers. Otherwise, it's just "the Java flavor of OpenLID". My $.02. - Curtis On Feb 26, 2008, at 1:14 PM, Asa Hardcastle wrote: > I see where Conor is coming from and where Scott is coming from. > > OpenLiberty-J sounds good, I also like the uppercase "O" -- makes > it look stronger. The differentiation between wsc and wsp is > important, however, as we have discussed many times before, the lines > are very blurry. The tooling that we have done for WSC would be re- > useable for a WSP. > > The only problem is that openLiberty covers more than ID-WSF at then > moment. Maybe that should change. OpenLiberty could still be the > location of the work until the projects are under the apache > foundation (kind of like the apache foundation itself -- apache is a > webserver and a foundation) > >> OpenLiberty-J would be the java implementations of the ID-WSF > specifications > > The package structure would determine the use (as it does now): > > org.openliberty.wsc > -- where the wsc code currently exists > > org.openliberty.xmltooling > -- where the base package for all of the java objects that represent > the xml elements of the spec currently exist, eg, > org.openliberty.xmltooling.disco > > org.openliberty.wsp > -- base packagewhere WSP code might be > > > On the level of documentation, creating clear segregation between > client and server is critical. I imagine this would be done with use > case sample code. > > Ideally we could get identity into the name in some way, and web > services for that matter. And it should be catchy. OpenLiberty-J is > catchy. > > Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: > > idSTAR-J > > IDStar-J > > OpenLID-J > > OpenLIDStar-J > > LibertyStar-J > > OpenLID*-J > > > > later, > > asa > > > On Feb 26, 2008, at 11:46 AM, Scott Cantor wrote: > >>> I think it is worthwhile differentiating between a client and a >>> server >>> implementation when we talk about the stuff. So perhaps >> OpenLiberty-J-Client or >>> something that indicates it's the client side of Liberty in Java. >> >> And we rejected that because to most people client means something >> they run >> on their desktop. >> >> So I've said my peace (again)...I think it should be one name, and >> don't >> agree with splitting client and server. >> >> -- Scott >> >> >> >> _______________________________________________ >> Wsf-dev mailing list >> Wsf-dev at lists.openliberty.org >> http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org > > -- > Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib > Tel: +1.413.429.1044 Skype: subsystem7 > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org > From dick at sxip.com Tue Feb 26 10:30:06 2008 From: dick at sxip.com (Dick Hardt) Date: Tue, 26 Feb 2008 10:30:06 -0800 Subject: [wsf-dev] naming? In-Reply-To: <70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> <70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> Message-ID: <0A7A9BF4-4796-4205-9FD8-A1E7D268D02F@sxip.com> I would suggest that is too close to OpenID which does have a tm and given the confusion, I would recommend that they enforce. -- Dick On 26-Feb-08, at 10:26 AM, Curtis Jones wrote: > I vote for "OpenLID" -- catchy, and has lots of marketing > possibilities. The only downside is that it's pretty damn close to > "OpenID" -- but it wouldn't be the first such set of similarly named > libraries in the same space (e.g., TAPI vs TSAPI). I'd personally > keep it simple/clean and leave off the "-J" except for actual package > names or part numbers. Otherwise, it's just "the Java flavor of > OpenLID". > > My $.02. > > - Curtis > > > On Feb 26, 2008, at 1:14 PM, Asa Hardcastle wrote: > >> I see where Conor is coming from and where Scott is coming from. >> >> OpenLiberty-J sounds good, I also like the uppercase "O" -- makes >> it look stronger. The differentiation between wsc and wsp is >> important, however, as we have discussed many times before, the lines >> are very blurry. The tooling that we have done for WSC would be re- >> useable for a WSP. >> >> The only problem is that openLiberty covers more than ID-WSF at then >> moment. Maybe that should change. OpenLiberty could still be the >> location of the work until the projects are under the apache >> foundation (kind of like the apache foundation itself -- apache is a >> webserver and a foundation) >> >>> OpenLiberty-J would be the java implementations of the ID-WSF >> specifications >> >> The package structure would determine the use (as it does now): >> >> org.openliberty.wsc >> -- where the wsc code currently exists >> >> org.openliberty.xmltooling >> -- where the base package for all of the java objects that represent >> the xml elements of the spec currently exist, eg, >> org.openliberty.xmltooling.disco >> >> org.openliberty.wsp >> -- base packagewhere WSP code might be >> >> >> On the level of documentation, creating clear segregation between >> client and server is critical. I imagine this would be done with use >> case sample code. >> >> Ideally we could get identity into the name in some way, and web >> services for that matter. And it should be catchy. OpenLiberty-J is >> catchy. >> >> Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: >> >> idSTAR-J >> >> IDStar-J >> >> OpenLID-J >> >> OpenLIDStar-J >> >> LibertyStar-J >> >> OpenLID*-J >> >> >> >> later, >> >> asa >> >> >> On Feb 26, 2008, at 11:46 AM, Scott Cantor wrote: >> >>>> I think it is worthwhile differentiating between a client and a >>>> server >>>> implementation when we talk about the stuff. So perhaps >>> OpenLiberty-J-Client or >>>> something that indicates it's the client side of Liberty in Java. >>> >>> And we rejected that because to most people client means something >>> they run >>> on their desktop. >>> >>> So I've said my peace (again)...I think it should be one name, and >>> don't >>> agree with splitting client and server. >>> >>> -- Scott >>> >>> >>> >>> _______________________________________________ >>> Wsf-dev mailing list >>> Wsf-dev at lists.openliberty.org >>> http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org >> >> -- >> Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib >> Tel: +1.413.429.1044 Skype: subsystem7 >> >> >> _______________________________________________ >> Wsf-dev mailing list >> Wsf-dev at lists.openliberty.org >> http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org >> > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org > > From peter.davis at neustar.biz Tue Feb 26 10:31:44 2008 From: peter.davis at neustar.biz (Peter Davis) Date: Tue, 26 Feb 2008 13:31:44 -0500 Subject: [wsf-dev] naming? In-Reply-To: <70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> <70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> Message-ID: <0D3B2F99-4556-4155-8932-613897E2CD34@neustar.biz> On Feb 26, 2008, at 1:26 PM, Curtis Jones wrote: > OpenLID the trouble with this name, is potential confusion with Johannes Ernst's earler work: LID =peterd From brett at projectliberty.org Tue Feb 26 10:34:57 2008 From: brett at projectliberty.org (Brett McDowell) Date: Tue, 26 Feb 2008 13:34:57 -0500 Subject: [wsf-dev] naming? In-Reply-To: <2221701493653654254@unknownmsgid> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <2221701493653654254@unknownmsgid> Message-ID: When people talk about those projects (Xerces-J, Xerces-C, OpenSAML-J, etc.) what do they say out loud? Do they say "xerces Java code" and "openSAML's Java stack" etc., or do they say "xerces-C" and "openSAML-C" etc.? For example I have only ever heard of openSAML as "openSAML" but I knew there was both a C version and a Java version. So if that flies maybe we could name our project openLiberty-J and openLiberty-C but it would be "openLiberty" in discussion. To Curtis and Asa: there is a problem using "LID". Not only is openLID too close to OpenID, but LID is the name of another initiative in this space "Lightweight IDentity". On Tue, Feb 26, 2008 at 11:17 AM, Scott Cantor wrote: > > Did you literally mean "openLiberty-J" or is "-J" a placeholder for a > name > > for this subproject TBD? > > No, I mean literally. Xerces is split into Xerces-J and Xerces-C, for > example, as is OpenSAML (because I copied it). > > Basically, I don't think deployers out there understand or care about any > distinctions inside ID-WSF. If they're at all interested, they'll expect > the > package to include it all and just need to know what's actually > implemented > inside the release notes. > > In Java, in particular, you only load classes that you use, so it doesn't > matter how much you bundle into one. > > -- Scott > > > -- Brett McDowell, +1-413-652-1248, www.projectliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080226/cf9c96ec/attachment.html From conor.p.cahill at intel.com Tue Feb 26 10:35:12 2008 From: conor.p.cahill at intel.com (Cahill, Conor P) Date: Tue, 26 Feb 2008 10:35:12 -0800 Subject: [wsf-dev] naming? In-Reply-To: <0D3B2F99-4556-4155-8932-613897E2CD34@neustar.biz> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net><-8098376148395210412@unknownmsgid><4647544322378513577@unknownmsgid><051101c87893$0b587010$22095030$%2@osu.edu><1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com><052c01c87897$2f7d1320$8e773960$%2@osu.edu><6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net><70916B3C-8B49-4623-B2E7-2FFD44F68E99@upto11.com> <0D3B2F99-4556-4155-8932-613897E2CD34@neustar.biz> Message-ID: <1B47D24854C7BC4FA8DA28BEBB59B0BA0307238F@orsmsx419.amr.corp.intel.com> OpenLIBID :-). Sounds like some kind of disease... Conor > -----Original Message----- > From: wsf-dev-bounces at lists.openliberty.org [mailto:wsf-dev- > bounces at lists.openliberty.org] On Behalf Of Peter Davis > Sent: Tuesday, February 26, 2008 1:32 PM > To: Curtis Jones > Cc: wsf-dev at openliberty.org > Subject: Re: [wsf-dev] naming? > > On Feb 26, 2008, at 1:26 PM, Curtis Jones wrote: > > > OpenLID > > the trouble with this name, is potential confusion with Johannes > Ernst's earler work: LID > > =peterd > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf- > dev_lists.openliberty.org From cantor.2 at osu.edu Tue Feb 26 10:44:08 2008 From: cantor.2 at osu.edu (Scott Cantor) Date: Tue, 26 Feb 2008 13:44:08 -0500 Subject: [wsf-dev] naming? In-Reply-To: <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> Message-ID: <054f01c878a7$924bc590$b6e350b0$@2@osu.edu> > OpenLiberty-J sounds good, I also like the uppercase "O" -- makes > it look stronger. That one happened while I wasn't looking, and I tend to interchange them because I like OpenLiberty more than openLiberty. > The differentiation between wsc and wsp is > important, however, as we have discussed many times before, the lines > are very blurry. The tooling that we have done for WSC would be re- > useable for a WSP. Which is why I don't make the distinction. Another example...Axis doesn't come in a SOAP client and server version. It's just different parts of the package. > The only problem is that openLiberty covers more than ID-WSF at then > moment. My scope of ID-WSF is everything Liberty does that's not SAML. Admittedly overly broad. My point is kind of that even if other non-WSF stuff is in the pot, who cares? > org.openliberty.xmltooling > -- where the base package for all of the java objects that represent > the xml elements of the spec currently exist, eg, > org.openliberty.xmltooling.disco Just a personal opinion, but I would have turned it around and put the XML classes inside the disco package. > On the level of documentation, creating clear segregation between > client and server is critical. I imagine this would be done with use > case sample code. Yes, that's a different issue. > Ideally we could get identity into the name in some way, and web > services for that matter. And it should be catchy. OpenLiberty-J is > catchy. Well, it's not super catchy, but it's better than something with WSF in it. You're not talking to somebody in marketing. To me Shibboleth is "catchy" and I've been told it sucks, so...(in fairness I didn't come up with that name either). > Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: ID-FF is superseded, and I lump all the rest into ID-WSF, as I said. > idSTAR-J I think I would avoid anything like STAR. > OpenLID-J There was an OpenID competitor called LID, best to avoid that. The basic problem is that there's no catchy name for ID-WSF. Unless you just make up a name that's unrelated, it just doesn't lend itself to anything. And speaking frankly, WSF is too unknown to developers to call it "Possum" and just say "yeah, that's the WSF library". Liberty at least has a known name. -- Scott From pulkitsinghal at gmail.com Tue Feb 26 12:36:51 2008 From: pulkitsinghal at gmail.com (Pulkit Singhal) Date: Tue, 26 Feb 2008 12:36:51 -0800 Subject: [wsf-dev] naming? In-Reply-To: <4006375368447726318@unknownmsgid> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> <4006375368447726318@unknownmsgid> Message-ID: <15dcf8060802261236s38576bd1u38c5b1f675477561@mail.gmail.com> I agree with Scott about: ==== WSF is too unknown to developers to call it "Possum" and just say "yeah, that's the WSF library" ==== But just for kicks, in case it ends up flying, I'd like nominate the name: "Behemoth". Yes I understand the connotation about being large and overbearing but I just couldn't keep quiet after reading the discussion ... its been floating around in my head since I started working with web services. Just a pet-peeve feel free to ignore. Cheers! On Tue, Feb 26, 2008 at 10:44 AM, Scott Cantor wrote: > > OpenLiberty-J sounds good, I also like the uppercase "O" -- makes > > it look stronger. > > That one happened while I wasn't looking, and I tend to interchange them > because I like OpenLiberty more than openLiberty. > > > The differentiation between wsc and wsp is > > important, however, as we have discussed many times before, the lines > > are very blurry. The tooling that we have done for WSC would be re- > > useable for a WSP. > > Which is why I don't make the distinction. Another example...Axis doesn't > come in a SOAP client and server version. It's just different parts of the > package. > > > The only problem is that openLiberty covers more than ID-WSF at then > > moment. > > My scope of ID-WSF is everything Liberty does that's not SAML. Admittedly > overly broad. My point is kind of that even if other non-WSF stuff is in > the > pot, who cares? > > > org.openliberty.xmltooling > > -- where the base package for all of the java objects that represent > > the xml elements of the spec currently exist, eg, > > org.openliberty.xmltooling.disco > > Just a personal opinion, but I would have turned it around and put the XML > classes inside the disco package. > > > On the level of documentation, creating clear segregation between > > client and server is critical. I imagine this would be done with use > > case sample code. > > Yes, that's a different issue. > > > Ideally we could get identity into the name in some way, and web > > services for that matter. And it should be catchy. OpenLiberty-J is > > catchy. > > Well, it's not super catchy, but it's better than something with WSF in > it. > You're not talking to somebody in marketing. To me Shibboleth is "catchy" > and I've been told it sucks, so...(in fairness I didn't come up with that > name either). > > > Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: > > ID-FF is superseded, and I lump all the rest into ID-WSF, as I said. > > > idSTAR-J > > I think I would avoid anything like STAR. > > > OpenLID-J > > There was an OpenID competitor called LID, best to avoid that. > > The basic problem is that there's no catchy name for ID-WSF. Unless you > just > make up a name that's unrelated, it just doesn't lend itself to anything. > And speaking frankly, WSF is too unknown to developers to call it "Possum" > and just say "yeah, that's the WSF library". Liberty at least has a known > name. > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > > http://lists.openliberty.org/mailman/listinfo/wsf-dev_lists.openliberty.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080226/cbf51609/attachment.html From asa.openliberty at zenn.net Tue Feb 26 14:52:08 2008 From: asa.openliberty at zenn.net (Asa Hardcastle) Date: Tue, 26 Feb 2008 17:52:08 -0500 Subject: [wsf-dev] naming? In-Reply-To: <15dcf8060802261236s38576bd1u38c5b1f675477561@mail.gmail.com> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net> <-8098376148395210412@unknownmsgid> <4647544322378513577@unknownmsgid> <051101c87893$0b587010$22095030$%2@osu.edu> <1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com> <052c01c87897$2f7d1320$8e773960$%2@osu.edu> <6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net> <4006375368447726318@unknownmsgid> <15dcf8060802261236s38576bd1u38c5b1f675477561@mail.gmail.com> Message-ID: <58939657-D356-4D51-ACC5-7AFA1A8DD316@zenn.net> Hmm... Behemoth (although very memorable) is not quite the image I would like to portray ;) > And speaking frankly, WSF is too unknown to developers to call it > "Possum" and just say "yeah, that's the WSF library". Liberty at > least has a known name. One could use the same argument for naming it Possum. Maybe PossumID. Ha-neh-al-enji -- Navajo for "making talk" -- world war II code talkers used it to mean "communication" It has a good back story, and we are facilitating private How about "enji" enji-j enji-r enji-c enji-n Really the challenge is getting the product in-front of developers, into developers hearts, and living in some serious use cases. There need to be business reasons for developers to get involved. Anyone who is looking around for identity based web services will find liberty and openliberty, and then find Possum/enji/openLiberty/ Behemoth/Yeti The identity market is filled with things that have ID/Ident/Open/ Identity/Services in their names. asa On Feb 26, 2008, at 3:36 PM, Pulkit Singhal wrote: > I agree with Scott about: > ==== > WSF is too unknown to developers to call it "Possum" and just say > "yeah, that's the WSF library" > ==== > > But just for kicks, in case it ends up flying, I'd like nominate > the name: "Behemoth". Yes I understand the connotation about being > large and overbearing but I just couldn't keep quiet after reading > the discussion ... its been floating around in my head since I > started working with web services. Just a pet-peeve feel free to > ignore. > > Cheers! > > On Tue, Feb 26, 2008 at 10:44 AM, Scott Cantor > wrote: > > OpenLiberty-J sounds good, I also like the uppercase "O" -- makes > > it look stronger. > > That one happened while I wasn't looking, and I tend to interchange > them > because I like OpenLiberty more than openLiberty. > > > The differentiation between wsc and wsp is > > important, however, as we have discussed many times before, the > lines > > are very blurry. The tooling that we have done for WSC would be re- > > useable for a WSP. > > Which is why I don't make the distinction. Another example...Axis > doesn't > come in a SOAP client and server version. It's just different parts > of the > package. > > > The only problem is that openLiberty covers more than ID-WSF at then > > moment. > > My scope of ID-WSF is everything Liberty does that's not SAML. > Admittedly > overly broad. My point is kind of that even if other non-WSF stuff > is in the > pot, who cares? > > > org.openliberty.xmltooling > > -- where the base package for all of the java objects that > represent > > the xml elements of the spec currently exist, eg, > > org.openliberty.xmltooling.disco > > Just a personal opinion, but I would have turned it around and put > the XML > classes inside the disco package. > > > On the level of documentation, creating clear segregation between > > client and server is critical. I imagine this would be done with > use > > case sample code. > > Yes, that's a different issue. > > > Ideally we could get identity into the name in some way, and web > > services for that matter. And it should be catchy. OpenLiberty- > J is > > catchy. > > Well, it's not super catchy, but it's better than something with > WSF in it. > You're not talking to somebody in marketing. To me Shibboleth is > "catchy" > and I've been told it sucks, so...(in fairness I didn't come up > with that > name either). > > > Since ID-* is shorthand for ID-WSF, ID-SIS, ID-FF: > > ID-FF is superseded, and I lump all the rest into ID-WSF, as I said. > > > idSTAR-J > > I think I would avoid anything like STAR. > > > OpenLID-J > > There was an OpenID competitor called LID, best to avoid that. > > The basic problem is that there's no catchy name for ID-WSF. Unless > you just > make up a name that's unrelated, it just doesn't lend itself to > anything. > And speaking frankly, WSF is too unknown to developers to call it > "Possum" > and just say "yeah, that's the WSF library". Liberty at least has a > known > name. > > -- Scott > > > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf- > dev_lists.openliberty.org > > _______________________________________________ > Wsf-dev mailing list > Wsf-dev at lists.openliberty.org > http://lists.openliberty.org/mailman/listinfo/wsf- > dev_lists.openliberty.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080226/938155d0/attachment-0001.html From bliong at melcoe.mq.edu.au Tue Feb 26 15:20:20 2008 From: bliong at melcoe.mq.edu.au (Bruc Liong) Date: Wed, 27 Feb 2008 10:20:20 +1100 Subject: [wsf-dev] naming? In-Reply-To: <58939657-D356-4D51-ACC5-7AFA1A8DD316@zenn.net> References: <0155A755-5F6E-40C6-A6B3-511C558657DD@zenn.net><-8098376148395210412@unknownmsgid><4647544322378513577@unknownmsgid><051101c87893$0b587010$22095030$%2@osu.edu><1B47D24854C7BC4FA8DA28BEBB59B0BA0307223C@orsmsx419.amr.corp.intel.com><052c01c87897$2f7d1320$8e773960$%2@osu.edu><6D0FA129-07A2-4275-8A69-6153773CD0A6@zenn.net><4006375368447726318@unknownmsgid><15dcf8060802261236s38576bd1u38c5b1f675477561@mail.gmail.com> <58939657-D356-4D51-ACC5-7AFA1A8DD316@zenn.net> Message-ID: <4586F70FAC74524A9F537C07CCC25AE3DED839@london.MELCOE.local> My vote for OpenLiberty-J. Simple, catchy, and not really that bothered with -J (most developers already educated to know -J only for implementation choice, not project name). As for client-server separation, this can be easily addressed by documentation and use-cases presented with the software. Enji-* doesn't stick that well unfortunately. It will ended up as "another project with weird name and we'll look at it when we have time". My .02c Bruc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3589 bytes Desc: not available Url : http://lists.openliberty.org/pipermail/wsf-dev_lists.openliberty.org/attachments/20080227/028f8dd8/attachment.bin