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] | [List Home]

Subject: FW: [wss] New Issue: KeyIdentifier ValueTypes

This issue was missed in Issues List 17


-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Tuesday, June 03, 2003 1:53 AM
To: wss@lists.oasis-open.org
Subject: [wss] New Issue: KeyIdentifier ValueTypes

The core spec currently takes the position that the ValueType which
optionally appears in the KeyIdentifier describes the thing referred to,
e.g. an X.509 cert, rather than the type of the KeyIdentifier itself. In
fact the spec says even if it does appear, it is only a hint.

This does not seem particularly useful. If the KeyIdentifier allows you to
find the thing (currently it is the only clue) then either you know that
since you are digging through a haystack you must be looking for needles, or
alternatively, once you get your hands on this object you can see for
yourself what sort of thing it is and you don't need a hint. (Not that a
hint about how big it is wouldn't be useful, but I digress.)

I am pretty sure I recall, on the last call we discussed how there are
various different schemes for creating a fingerprint or unique value which
might be used as a KeyIdentifier to refer to a Cert or key. If there
potentially are a number of schemes for each token type it seems like it
would be useful to have a ValueType that told you the scheme used by this
particular KeyIdentifier and also implied the token types that scheme could
be used with. For example, a hash of the "whole thing" could be used to
identify a Kerberos ticket as well as an X.509 cert. Or perhaps each scheme
should be linked to exactly one token type, I don't feel strongly. But it
seems clear we need to allow more than one scheme per token type.

Under this proposal the encoding type would also refer to the KeyIdentifier,
not the thing identified. For example, for a binary hash, it could specify
base 64, hex or some future format for binary data in XML.

This seems to me to be completely consistent with the decision taken
previously to direct profile editors to define one or more (zero or more?)
KeyIdentifier schemes to be used with their Token type.


You may leave a Technical Committee at any time by visiting

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