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] Proposal to Label Tokens to Indicate Their Semantics


Title: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics

 [...]

> Two questions:
> 1) Do we need ability to associate the <tokens> together to represent
>    all participating entities? [For the sake of this discussion, these
>    entities are being referred to as participants in remaining part of
>    this discusison]

All I was proposing was that in many situations, it would simplify policy processing to know that some of the tokens referred to the same system entity. It is often the case that users have multiple tokens and frequently it is impossible to tell by inspecting them that they refer to the same entity.

I assume that all the tokens in the header would be relevant in some way to the message in question. The Purpose label was an attempt to disambiguate this.

However, I did not envision that a SOAP body might contain a number of unrelated messages each with its own seperate set of participants. While I concede that this possibility is not prohibited by the SOAP specification, it seems a poor and inefficient application design. Is this something you see as likely? DO you have a usecase in mind?

> 2) Since additional <tokens> element may be added, wouldn't
> it make sense to
> be
>    able to optionally encapsulate them together in some
> security header
> child
>    element?

I don't really understand this question. Do you mean added to the message or added to the schema? I have only proposed adding a single Tokens element to the schema. Perhaps this question is simply a restatement of the first one.

> Obviously, the decision of including tokens
> beyond the target
> node
>    itself is a privacy issue - that could be resolved
> independent of this
>    specification.
 
Now you really lost me. Is "target node" a defined term? Even if I take a guess at what that means, I am at a loss to interpret "tokens beyond the target node" Clearly there are privacy issues around any claims in any message. Generally it is assumed that any such information can be intercepted by a 3rd party unless it is encrypted.

I can see that grouping tokens so as to convey that they refer to to the same system entity raises privacy issues over and above the mere inclusion of these tokens. That is why:

1. I was careful not to suggest that the failure to group tokens implied that they represented distinc entities. In other words, you don't have to group them if you don't want to.

2. I have been trying to ecourage debate about how much semantics we need to specify in this standard, or how little we can get away with.

[...]

> W.r.t. abstract token construct carrying a Purpose attribute,
> currently all
> token elements defined
> in the Draft 1 of of the Web Services Core specification have an
> extensibility mechanism already
> available to allow the carrying of additional attributes,

Except that the XML tokens are "just inserted" so extending them requires extending (if possible) other schemas outside of wsse: Furthermore in the case of XML tokens, they will typically come already signed by some authority. In my proposal, the Purpose would fall outside of this signature (although within a message signature) because the same entity might take on different Purposes with respect to different messages, while being represented by the same token, e.g. a SAML assertion containing an Attribute Statement.

Hal



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


Powered by eList eXpress LLC