[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
Luc Clément <luc@iclement.net>
04/02/2004 12:18 AM |
|
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]