RE: [wss] Issue 308 - License Id in REL Token Profile

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Since we have an action to explore this issue more on the list, I offer
the following in the way of exploration.

If I understand this issue correctly, Hal observes the following
difference between Case 0 and Case 3I.

Case 0:
<wsse:Security>
	...
	<wsse:SecurityTokenReference>
		<wsse:Reference URI="http://www.licenses.com/?id=123"/>
	</wsse:SecurityTokenReference>
	...
</wsse:Security>

Case 3I:
<wsse:Security>
	...
	<r:license licenseId="urn:foo:SecurityToken:ef375268">
		...
	</r:license>
	...
	<wsse:SecurityTokenReference>
		<wsse:Reference URI="urn:foo:SecurityToken:ef375268"
	
ValueType="http://...-REL-token-profile-1.0#license"/>
	</wsse:SecurityTokenReference>
	...
</wsse:Security>

In Case 0, Hal observes that the remote reference URI is quite
"resolvable" and easily classifies as a Direct Reference.  In Case 3I,
he observes that the licenseId reference urn:foo:SecurityToken:ef375268
resembles a Key Identifier reference that could be resolved by looking
inside the token more than it resembles a Direct Reference.  These
observations support the idea that Case 0 and Case 3I are different.

In order to see in which ways Case 3I is similar to Case 0, I write out
here a number of intermediate cases between the two seeming extremes.

Case 0:
	http://www.licenses.com/?id=123 locates the license.
	r:license/@licenseId is absent.
	The license does not appear in the security header.
Case 1:
	http://www.licenses.com/?id=123 locates the license.
	r:license/@licenseId = http://www.licenses.com/?id=123.
	The license does not appear in the security header.
Case 1I:
	http://www.licenses.com/?id=123 locates the license.
	r:license/@licenseId = http://www.licenses.com/?id=123.
	The license appears in the security header.
Case 2:
	urn:isbn:1-234-56789-0 names the license.
	r:license/@licenseId = urn:isbn:1-234-56789-0.
	The license does not appear in the security header.
Case 2I:
	urn:isbn:1-234-56789-0 names the license.
	r:license/@licenseId = urn:isbn:1-234-56789-0.
	The license appears in the security header.
Case 3:
	urn:foo:SecurityToken:ef375268 names the license.
	r:license/@licenseId = urn:foo:SecurityToken:ef375268.
	The license does not appear in the security header.
Case 3I:
	urn:foo:SecurityToken:ef375268 names the license.
	r:license/@licenseId = urn:foo:SecurityToken:ef375268.
	The license appears in the security header.

Looking at the above cases, one can see that Case 1 is just like Case 0,
except for the fact that in Case 1 the license happens to have some
extra information in the licenseId attribute.  A security processor
should be able to handle Case 0 and Case 1 in the same way, ignoring
such extra information.

The only difference between Case 1 and Case 1I is that in Case 1I the
license happens to also be carried in the security header.  A security
processor should be able to handle Case 1 and Case 1I in the same way if
it wants to, but should also have the added ability in Case 1I to
optionally extract the license from the security header to save having
to make a connection to www.licenses.com to retrieve the license.  In
the case of extracting the license from the security header, the
issuer's signature can be checked to give confidence that the license in
the signature is actually the one that would be retrieved from
www.licenses.com.  In any event (whether the license is retrieved from
www.licenses.com or extracted from the security header), the ultimate
make-or-break decision (of whether the receiver has the correct intended
license) would be based on the sender's signature over the message body
and license.  So Case 1 and Case 1I should be able to be handled in the
same way.

The only difference between Cases 1 and 1I and Cases 2 and 2I is that
Cases 2 and 2I use name-based identifiers rather than location-based
identifiers.  In order to support HTTP location-based identifiers, the
receiver needs to have an HTTP client to resolve the locations.  In
order to support ISBN name-based identifiers, the receiver needs to have
access to some repository indexed by ISBN.  Whereas in Case 1 the
license is always retrieved from www.licenses.com, in Case 2 the license
can be retrieved from any computer that has an ISBN repository.  For
instance, one implementation might look up the ISBN in the library of
congress.  Another implementation might look up the ISBN in a private
collection.  Both lookups should result in the same license (we assume
the license in this case is published as a book and has its own ISBN).
Since the only implementation difference between Case 1 and Case 2 is
the type of URI resolving capabilities on the receiver, the two cases
should be processed (and therefore represented) in a similar manner.

The only difference between Cases 2 and 2I and Cases 3 and 3I is that
Cases 2 and 2I use a well-known naming scheme (ISBN) while Cases 3 and
3I use a lesser-known naming scheme (FOO).  Certainly, the degree to
which a naming scheme is known should not affect the processing model,
and therefore Cases 3 and 3I should processed (and therefore
represented) the same as Cases 2 and 2I.

Putting this all together, it follows that Case 3I should be able to be
processed the same as Case 0.  Since there is no disagreement that Case
0 should be a Direct Reference, it follows that representing Case 3I as
a Direct Reference is consistent.

&Thomas.

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Monday, July 12, 2004 8:06 PM
To: wss@lists.oasis-open.org
Subject: [wss] New Issue - License Id in REL Token Profile

The REL Token Profile specifies 3 ways the a STR can refer to an XrML
license: remote URL, local URL fragment and LicenseId. This seems fine
to me. However, the LicenseId is defined as a direct reference. I
believe it should be defined as a KeyIdentifier. This is consistent with
what has been proposed for X.509 Tokens in the case of IssuerSerial and
with the current way that the SAML Token Proifiles specifies the use of
an AssertionId.

I believe that the various Token profiles should be as consistent as
possible with each other in their use common mechanisms, such as
reference types in STRs. This will help to reduce programming errors and
facilitate future evolution of the specs.

The core spec does not really make clear when each type of reference is
intended to be used, but this is my understanding.

Direct references are intended to indicate the token by its location.
Usually if will be a dereferencible remote or local URL. If not, it will
be some kind of well understood URI, which lets you "find" the token. It
will usually not be related to the content of the Token. Therefore,
different references may point to copies of the same token and as the
token moves around the net or appears in different messages, its
references may change.

A Key Identifier is intended to be some identifier that appears within
the token and is unique to the token or its key. Usually it will be
under the signature of the issuer. It may or may not be a URI, but its
value will always be the same for the same token.

A Key Name is an identifier that refers to the subject of the token.
There may be a many to many relationship between the subject, token and
its keys.

Since we have largely deprecated the use of Key Name, then if we are
going to use direct references for things like License Id, IssuerSerial
and Assertion Id, they we might as well drop the use of Key Identifier
and Key Name entirely and just use direct references for everything.

Hal

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/wss/members/leave_workgroup
.php.