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


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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

Subject: RE: [wss] Web Services Security Username Token Profile

Gene Thurston wrote:

> Thanks for the comments, Zahid.
> I agree that in practice SSL/TLS can, and will often (usually?), be used
> to provide these capabilities.  I still believe, however, that we should
> address cases where transport level security is either not an option, or
> for some other reason (application specific, perhaps) is not being used.
> On the XML Signature spec, the use of other algorithms will not break
> our compliance with the standard.  While the spec does define
> identifiers for the DSA and RSA algorithms, it is intended to be
> extensible: "... the mechanism is extensible; alternative algorithms may
> be used by signature applications."  This is analogous to the extensions
> in the <ds:KeyInfo> element, or the definition of Transform URIs, both
> of which we are currently planning to use for SecurityTokenReferences.
Taking a look at the certificates shipped with my browser, it's would
seem that RSA is dominant, not DSA. And PBE has long been a
feature of the landscape.

I guess I'd prefer to see RSA with SHA-1 required and RSA with MD5
allowed. I don't think making DSA a requirement is particularly realistic,
just some politics. But generally, I'd rather support extensibility and let
the market decide. Different communities will have different requirements.

> I actually have no problem with your idea of keeping the existing
> Username token profile (using nonce, creation timestame, digests, etc.),
> and perhaps adding a second Username profile which would provide the
> binding with the message.  This was, in fact, where my thinking was
> headed, as well.
I'd prefer to keep this all in one document rather than grow more and
more variations. And for me, adding a biometric template as an optional
parameter to a user name and password is merely a wrinkle to the
current work, not something that's worthy of a separate document.

> I do think, however, that we need to point out the security issues in
> the Threat Model, and at least state that secure transports can
> alleviate these concerns.  (But, then again, if you are using a secure
> transport, why bother doing anything more than sending the password in
> clear text?)
In a simple case this might be fine. But I can see a case for sending an
encrypted password to a recipient who forwarded the value on to a
trusted authority that determined whether or not it was valid. A merchant
- bank - customer transaction might need to do that, or a mobile provider
hooking up a customer to a merchant and bank could lead to this sort of

But my biggest concern right now is process. How do we move the
Username document forward without excessive delay or impacting the
Core work? Seems to me we need a SC to go off and do the work
on this document, then bring it back and try to sell the result to WSS


Thanks, again,

- Gene -

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

Powered by eList eXpress LLC