OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] Groups - uddi-spec-tc-tn-httpauth-20040316.doc uploaded



I think the HTTP authentication note is necessary simply because several shipping UDDI products have the option of using HTTP Auth for the UDDI Web services.

The WS-Security note is almost ready for posting/review and I believe it is well aligned with the WS-* specs listed below as well as the WS-I Basic Security Profile.  The reason it hasn't yet been posted is because I included some information from WS-I that I shouldn't have included and noticed before the NZ F2F meeting.  I've almost got that stripped out of the document and may even post it today.

My goal is that nothing in the WS-Security note that ties it to the WS-* specs or WS-I specifically, but that we provide the modeling framework that complements using those specs for profiles and overviewDocuments when acceptable IP statements are available.  There's enough modelling to just cover mechanism use... and as time goes on, the mechanism use would be specified as a policy (so just another overviewDoc would be added).

Regards,

Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies
Lotus Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512) 838-2866,  t/l 678-2866



Luc Clément <luc@iclement.net>

04/02/2004 12:18 AM

To
Andrew Hately/Austin/IBM@IBMUS, <uddi-spec@lists.oasis-open.org>
cc
Subject
RE: [uddi-spec] Groups - uddi-spec-tc-tn-httpauth-20040316.doc uploaded





Andrew,

Thanks for taking the time to write this proposal. I have a few concerns that I'd like to express.

Relationship with ws-policy, ws-security, ws-trust and ws-securityPolicy

I'm concerned about taking the approach you are considering: authentication type specific tModel references from the binding template to http basic and http md5 digest auth mechanisms. My concerns are related to the modeling choices made by this TN that may not necessarily align to the model we would chose to adopt if we were considering ws-policy/ws-security/ws-trust/ws-securityPolicy. I would hate for us to author a TN that proposed a model for basic and md5-digest http auth that did not align with how we would model if we were considering ws-policy/ws-security/ws-trust/ws-securityPolicy as the framework to express Web service authentication mechanisms.

Would we be better to sit on our hands for a while until (and if) ws-policy, ws-trust and ws-securityPolicy are available to us (from an IP perspective)? This is a difficult question to answer particularly given IP issues related to each of these specs. I think we need to consider the above before we decide jumping in too far. Getting some clarity on IP-related matter wrt ws-policy would help a great deal.

Token-based mechanisms

While http basic and md5 digest auth are fine mechanims, ws-security (and a set of related specs) offer alternative set of ws-security-based mechanisms as depicted by this list of tokens under consideration by ws-securitypolicy:

QName Description
wsse:X509v3 X.509 v3 certificate
wsse:Kerberosv5TGT Kerberos V5 Ticket Granting Ticket
wsse:Kerberosv5ST Kerberos V5 service ticket
wsse:UsernameToken Username token defined in WS-Security
wsse:SAMLAssertion SAML Assertion
wsse:XrMLLicence XrML Licence

While issuing a TN dealing with HTTP-specific mechanisms is a fine short-term goal, I'm concerned that by not considering ws-security/policy based approaches that the model we chose for http-based auth schemes may not align with what we would consider for ws-security-based schemes (within the context of ws-policy). This repeats my concerns from above.

I think we need more debate this and decide whether in fact issuing the TN specifically targetted to http-based auth mechanisms based on your proposal is the best longer term approach. What would help greatly is getting a reading on IP-related issues particularly on ws-policy; getting this sorted out would help us all.

In closing, I'm not against the solution you propose, but I think that by not considering the issues that I've pointed out we run the risk of releasing a TN that may quickly be obsoleted. I'd hate for us not to make progress on this important topic but would like further discussion as to what our roadmap is in regard to my concerns before we push on.

Luc

Luc Clément
                                                         
Web:        www.iclement.net/luc  
Cell:         425.941.0150

 

-----Original Message-----
From: hately@us.ibm.com [
mailto:hately@us.ibm.com]
Sent: Sunday, March 28, 2004 13:52
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Groups - uddi-spec-tc-tn-httpauth-20040316.doc uploaded

The document uddi-spec-tc-tn-httpauth-20040316.doc has been submitted by Andrew Hately (hately@us.ibm.com) to the OASIS UDDI Specification TC document repository.

Document Description:
First Draft of TN to satisfy part of REQ004

Download Document:

http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/6132/uddi-spec-tc-tn-httpauth-20040316.doc

View Document Details:

http://www.oasis-open.org/apps/org/workgroup/uddi-spec/document.php?document_id=6132


PLEASE NOTE:  If the above links do not work for you, your email application may be breaking the link into two pieces.  You may be able to copy and paste the entire link address into the address field of your web browser.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]