[wss] wrapping, references, usage annotation, and transforms

[ronald monzillo <ronald.monzillo@sun.com>]

In today's call I agreed to start this thread, so
here goes.

--------

wrapping is currently used to encapsulate binary
security tokens both as a way to identify the
encoding of the encapsulated token, and as a way
to associate identification (and other)
attributes with the token.

wrapping is not currently used to associate usage
annotations with security tokens because it was held
that such a scheme would create a 1-1 relationship
between a token and its usage information. It was also
held that it was more important to be able to associate
annotations with the use of a token (such as in a
signature) than to annotate a token to describe
why the token is present in the msg. The last point
being a relative one; that is may be that there are cases
where there is benefit to associating annotations
with security tokens that describe why they are present
(outside of the context of a specific use).

The STR element was created to provide a unification
point for references to security tokens. The STR element
encapsulates token specific reference forms within a common
extensible element. STRs may be used to reference security
tokens in the context of a specific use of a token (such as
from dsig keyinfo), or independent of any specific use.

The TC agreed to add attributes to the STR element, to
allow STRs to carry usage annotations. This choice
was consistent with usage annotations being bound
to the context the use of a security token, and where an
STR occurs as a top level element it also provides for
usage annotations describing why a security token that is
not used in a context (such as a signature) is present
or referenced in the msg.

It seems that STRs cannot be (conveniently) used in
every context. One usage where we encountered a problem,
was the use of an STR in the reference element of
ds:signedInfo to indicate that a referenced security
token is to be signed. This is because security tokens
are referenced by token specific mechanisms, and the
ds:reference element has its own schema for referencing
the data that is to be signed (i.e 3 attributes ID, URI,
and Type, and the notion of a chain of Transforms,
initiated with the value of the URI attribute).
To allow signedInfo references to security tokens by way of
STRs, it was suggested that we define a transform
capable of dereferencing at least one STR.

It has been suggested that another way to solve the
signedInfo referencing problem and to provide for
usage annotation of security tokens would be to wrap
security tokens. It seems that such an approach could
produce security tokens that are uniformly referenceable
and capable of being annotated. It is unclear how
the use of wrapped tokens would be annotated, although
in the case of signatures, signature properties might
be used. Also, support of remote tokens would seem
to require a wraper that coud be remotely referenced,
or a way to wrap references to remote tokens; both of
which feel a lot like an STR.

It might be that a combination of STRs for usage
annotation and local references to wrapped security
tokens might do the trick given that the wrappers
export uniform local referencable identifiers
and encapsulate either an in-line token or a remote
token reference.