[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
Levinson, Richard wrote:
>Ron,
>
>Based on your previous email and the phone conversation we
>had yesterday that clarified the use cases in the email
>I have done some thinking about the ws message structures
>we can use to support the 4 use cases. I have included
>a first cut at something I think might work, where the
>WS Sig KeyInfo always points to an assertion whose subject
>is the invocation identity. The structures below incorporate
>the suggestions both of us have had in the course of these
>discussions and are meant to be a structure within which
>we can define the context of the use cases and the assertions
>and signatures necessary to support those use cases.
>Also, the main focus here is probably 2b with the other use
>cases leading up to it to provide a common context.
>
>Below are some defns and some use case scenarios that show the
>ws/saml message structures that can support those scenarios.
>
> Definitions:
>
> confirmation key: used to verify the signature on the
> message content.
>
> SAML Assertion Authority (saa)
>
> attr assertion: an assertion issued by the saa that contains
> some attributes that refer to the assertion subject.
> Basically the attester gets attr assertions from
> the saa.
>
> subject, attester, saa, recipient are set up as follows:
>
>
> +-------> saa
> | ^
> | |
> V V
> subject -> attester -> recipient
>
> In general, the subject gets authenticated by the saa and
> uses that authentication to interact with the attester in
> order to deliver messages to the recipient.
>
>The key is where the Security/Signature/KeyInfo STR (SSK STR) points.
>
>In all cases, we presume that subject has established identity relationship
>with saa and passes an indicator, such as a saml artifact to the attester
>to give the attester ability to contact the saa to get assertion
>related to subject. Also, in all cases the attester creates the
>ws signature.
>
>The key difference between 1* and 2* is that for 1* the recipient
>would rely on a business agreement with the attester for the
>purpose of dispute resolution, and in the 2* case the recipient
>would rely on a business agreement with the saa for the purpose
>of dispute resolution. In 2* the attester basically acts as an
>authorized agent of the saa to receive messages from users, get
>an assertion describing that user and packaging up a ws message
>that is sent to the recipient.
>
>
>1. attesting entity is authoritative for defining the confirmation
> key and confirms its knowledge of the key.
>
> a. the attesting entity is also authoritative for the
> contents of the assertion
>
> 1a. attester and saa are the same entity. SSK STR points to sv assertion
> in message. Assertion contains attester signature with verification
> key for both the assertion and the content. Recipient relies
> on attester.
>
>
> +-------------------+
> | content |<-+
> +-------------------+ |
> | subj sv/attr assn | |
> +->| attester env sig | |
> | +-------------------+ |
> | | ws sig ref |--+
> | +-------------------+
> +--| ws sig key info |
> +-------------------+
>
Rich,
In the preceding example, I presume the attester is putting a reference
to its key
somewhere. I guess that key could be in the "attester env sig", or it
could be
in the assertion subject conf. I am guessing it would be easier to
find/recognize if it
is in subject conf, but I am not sure. Moving the attester's key to the
signature, would
likely open up furthur simplification, as I'll try to depict below:
1a.
+-------------------+
| content |<---+
+-------------------+ |
+--->| subj sv assn | |
| | attester env sig | |
| | env sig keyValue | |
| +-------------------+ |
| | ws sig ref |----+
| +-------------------+
+----| ws sig key info |
+-------------------+
1b. done with 2 signatures in assertion is depicted below and
would require a change to the SAML schema to allow multiple
signatures in assertions. This approach would suggest
that the signers of the assertion that is also signing the msg content
is attesting for the subject in the context of the msg. This approach
would depend on the receiver being able to tell which signature
contains the key that it should use to validate the signature on the
msg content. One simple hueristic might be to expect the attestor signature
to be that last one added to the assertion
+-------------------+
| content |<---+
+-------------------+ |
+--->| subj sv assn | |
| | saa env sig | |
| | saa sig keyValue | |
| | attester env sig | |
| | env sig keyValue | |
| +-------------------+ |
| | ws sig ref |----+
| +-------------------+
+----| ws sig key info |
+-------------------+
As I understand your suggestion for 1b (below), you help the receiver understand
which signature is which, by separating them in different assertions;
.one attester signed assertion naming the subject and demonstrating the attestor key
.one saa and attesting entity signed (in different ways) assertion containing
the attributes of the subject (and bound by the attesting entity to the msg content).
>1. attesting entity is authoritative for defining the confirmation
> key and confirms its knowledge of the key.
>
> b. The assertion issuer is authoritative for the contents of
> the assertion other than the confirmation key.
>
> 1b. attester gets attr assertion from saa. Attester sig covers both the
> assertion and the content. SSK STR points to sv assertion
> in message with same subject as attr assertion. Attester signs
> the sv assertion. Recipient relies on attester.
>
> +-------------------+
> | content |<---+
> +-------------------+ |
> | subj attr assn |<-+ |
> +-------------------+ | |
> | subj sv assn | | |
> +->| attester env sig | | |
> | +-------------------+ | |
> | | ws sig ref |--+ |
> | +-------------------+ |
> | | ws sig ref |----+
> | +-------------------+
> +--| ws sig key info |
> +-------------------+
>
>
>2. assertion issuer is authoritative for defining the confirmation
> key and attesting entity confirms knowledge of key.
>
> a. issuer establishes confirmation key such that only the
> subject of the assertion can satisfy the confirmation
> method.
>
> 2a. attester and subject are the same entity. This is pure holder-of-key
> case. Subject gets hk assertion from saa. Subject uses private key
> to create sig w SSK STR pointing to hk assertion. Recipient relies
> on saa.
> (this should represent section 3.4.1.3 in WS-SAML Profile V9)
>
> +-------------------+
> | content |<-+
> +-------------------+ |
> | attester hk assn | |
> +->| saa env sig | |
> | +-------------------+ |
> | | ws sig ref |--+
> | +-------------------+
> +--| ws sig key info |
> +-------------------+
>
>
>
>2. assertion issuer is authoritative for defining the confirmation
> key and attesting entity confirms knowledge of key.
>
> b. issuer establishes confirmation key such that entities other
> than the the subject of the assertion can satisfy the
> confirmation method (i.e are authorized to impersonate the
> subject).
>
> 2b. attester is authorized by saa to impersonate subjects for whom it
> supplies assertions. Attester gets attr assertion signed by saa
> with saa attributes referring to subject. Attester signs
> sv assertion with same subject as attr assertion.
>
> How does SSK STR point to subject in 2b? Attester could sign
> sv assertion with sig that has KeyInfo that points to
> attester hk assertion, signed by saa.
>
> Recipient relies on saa.
>
> (this should represent section 3.4.2.3 in WS-SAML Profile V9,
> except that instead of the WS-KeyInfo pointing to an hk assertion
> it points to an sv assertion signed by the attester, which has
> a pointer to an hk assertion signed by the saa. Also rather than
> have ref 1 point to an str to an off message sv assertion, ref 1
> points to an onboard sv attr assn signed by the saa )
>
> +-------------------+
> | content |<---+
> +-------------------+ |
> | subj attr assn |<-+ |
> | saa env sig | | |
> +-------------------+ | |
> | subj sv assn | | |
> +--->| attester env sig | | |
> | +--| attester key info | | |
> | | +-------------------+ | |
> | | | attester hk assn | | |
> | +->| saa env sig | | |
> | +-------------------+ | |
> | | ws sig ref 1 |--+ |
> | +-------------------+ |
> | | ws sig ref 2 |----+
> | +-------------------+
> +----| ws sig key info |
> +-------------------+
>
>
Focusing on your proposed 2b formulation, I can see that the saa
is authorizing the contents of the first assertion (i.e. the
attributes that pertain to the subject), and the key binding
of the attester (in the third assertion).
I don't see how the saa is authorizing the impersonation
of the subject of the first and second assertions, by the subject
of the third assertion.
It would seem that the second assertion would need to be
signed by the saa for this to be the case.
Maybe you can clarify this.
Drawing a similar diagram for what the STP currently profiles,
the formulation would look as follows:
+-------------------+
| content |<---+
+-------------------+ |
+--->| subj hk assn | |
| | subConf keyInfo |--+ |
| | saa env sig | | |
| +-------------------+ | |
| | attester hk assn |<-+ |
| | subConf keyValue | |
| | saa env sig | |
| +-------------------+ |
| | ws sig ref |----+
| +-------------------+
+----| ws sig key info |
+-------------------+
which is a variation of the non-impersonation hok case (as currently profiled).
The variation is that an assertion of the attesting enity would be
referenced from the subject assertion.
+-------------------+
| content |<---+
+-------------------+ |
+--->| subj hk assn | |
| | subConf keyValue | |
| | saa env sig | |
| +-------------------+ |
| | ws sig ref |----+
| +-------------------+
+----| ws sig key info |
+-------------------+
Ron
>Let me know if you think this moves us closer to a
>framework that captures the requirements.
>
> Thanks,
>
> Rich
>
>
>
>>-----Original Message-----
>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
>>Sent: Monday, February 02, 2004 1:24 PM
>>To: Levinson, Richard
>>Cc: 'wss@lists.oasis-open.org '
>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>
>>
>>
>>Levinson, Richard wrote:
>>
>>
>>
>>>Ron,
>>>
>>>I have reviewed the rest of your comments and I believe
>>>we are in basic agreement on the principles involved,
>>>and what it really boils down to is how to implement
>>>
>>>
>>sender-vouches in
>>
>>
>>>a recognizable and efficient manner.
>>>
>>>
>>>
>>Rich,
>>
>>Sounds good.
>>
>>As I mentioned a few msgs ago, it is difficult with sv, to
>>set things up such that the attesting entity is authoritative
>>for the key binding, but not for the other contents of the
>>assertion. Maybe your proposed use of the assertion
>>signature, opens up a new way to accomplish this.
>>
>>IMO, the important (msg authentication) use cases are as follows:
>>
>>1. attesting entity is authoritative for defining the
>>confirmation key and
>> confirms its knowledge of the key.
>> a. the attesting entity is also authoritative for the contents of
>>the assertion
>> b. The assertion issuer is authoritative for the contents of the
>>assertion
>> other than the confirmation key.
>>
>>2. assertion issuer is authoritative for defining the
>>confirmation key
>>and attesting
>> entity confirms knowledge of key.
>> a. issuer establishes confirmation key such that only the
>>subject of
>>the assertion
>> can satisfy the confirmation method.
>> b. issuer establishes confirmation key such that entities
>>other than
>>the
>> the subject of the assertion can satisfy the confirmation method
>>(i.e are authorized
>> to impersonate the subject).
>>
>>Maybe there should also be variants of both 2a, and 2b, that
>>allow the
>>subject
>>of the assertion to be authoritative for some or all of the assertion
>>content
>>except the definition of the confirmation key.
>>
>>Any comments on the use cases?
>>
>>I suspect if we settle on use cases, it will be easier for us
>>to improve the related profile specific details.
>>
>>BTW, the SAML schema doesn't seem to allow multiple
>>signatures to be included in the assertion. If it did, maybe
>>the "difficult" sv case I noted above, which is case 1b in
>>the list of use cases, could be handled (in the signature
>>approach you proposed) by the attesting entity adding a
>>second signature to the assertion (using its key as keyInfo).
>>
>>Independent of how many signatures there are in the
>>assertion, the receiver of a sv confirmed assertion would
>>have to understand that the msg signature key must be a key
>>used to create a signature (within the assertion).
>>
>>I think the signature approach is interesting, but if we
>>accept the use cases enumerated above, I think we should
>>think a bit harder about how we might allow an attesting
>>entity, other than the assertion issuer, to authorize one or
>>more confirmation keys in subject confirmation.
>>
>>I realize that doing this would call into question SAML's
>>definition of KeyInfo in SubjectConfirmation, where the
>>identified key is supposed to be "held by the subject".
>>
>>
>>Ron
>>
>>
>>
>>>In particular, I agree with your comment:
>>>
>>>
>>>
>>>
>>>
>>>>I view a SAML holder of key confirmed assertion as an XML
>>>>certificate. The attesting entity could either use ists XML
>>>>certificate or its X509 XSN.1 certficate, they are logically
>>>>equivalent.
>>>>
>>>>
>>>>
>>>>
>>>From that perspective I think the only real issue is
>>
>>
>>>whether there is a root SAML authority that the recipient
>>>will trust, or whether the end of the line is always going
>>>to be an X.509 certificate issued by a recognized CA.
>>>
>>>If the latter is the case, then the question is when you
>>>shed the SAML wrapper for the signing key and use the
>>>X.509 wrapper.
>>>
>>>My inclination has been that since there are not yet any widely
>>>accepted SAML authorities, that common practice would generally end
>>>with an X.509 root.
>>>
>>>Assuming that to be the case, then the rest of the issues
>>>are kind of distinguishing between the 2 layer: subject plus
>>>"attester/assertion authority" where the subject is wrapped in an
>>>assertion and the a/aa uses an X.509 cert to end the chain;
>>>
>>>
>>and the 3
>>
>>
>>>layer: subject plus attester plus assertion authority, where
>>>
>>>
>>now both
>>
>>
>>>the subject and attester would have saml assertions and the aa would
>>>use an X.509 cert.
>>>
>>>If we assume a trusted root saml authority then possibly
>>>the X.509 cert in the above scenarios would be replaced
>>>by a root saml assertion.
>>>
>>>In these scenarios, the invocation identity is always the subject of
>>>the assertion, and the sender-vouches use case is determined by the
>>>fact that the recipient follows the Signature/KeyInfo and first
>>>encounters the sender-vouches assertion, which I am assuming, as
>>>suggested in my previous email is a signed assertion with an
>>>
>>>
>>enveloped
>>
>>
>>>signature signed by the attester.
>>>
>>> Rich
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Levinson, Richard
>>>>Sent: Sunday, February 01, 2004 10:29 AM
>>>>To: 'Ron Monzillo '; Levinson, Richard
>>>>Cc: 'wss@lists.oasis-open.org '
>>>>Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
>>>>
>>>>
>>>>
>>>>Ron,
>>>>
>>>>I am responding to your up front comment and
>>>>will look at the other comments tomorrow.
>>>>
>>>>As I understand what you are saying, you would
>>>>prefer that the Signature/KeyInfo always point
>>>>to a token containing the invocation identity.
>>>>
>>>>Although I had not looked at it from quite this
>>>>perspective, I agree that the sender-vouches as
>>>>currently construed has some questionable
>>>>characteristics.
>>>>
>>>>I think this arises from a basic shortcut that
>>>>is taken in the scenario which is having one
>>>>signature sign both the assertion and the message.
>>>>This saves time by only having one signature to
>>>>create but as you have indicated it starts to open
>>>>up all other sorts of issues. One that has always
>>>>troubled me is that it kind of breaks the atomicity
>>>>of the assertion token, such that the assertion is
>>>>not valid outside the context of the message. Also,
>>>>it puts the path to the invocation identity in
>>>>a Signature/Reference rather than a Signature/KeyInfo.
>>>>
>>>>In my opinion, the way this should be set up is that
>>>>the attester should first sign the assertion, and in
>>>>effect become the assertion authority (using an
>>>>enveloped signature), then sign the message using
>>>>standard WS practice, with the Signature/KeyInfo
>>>>pointing to the assertion.
>>>>
>>>>This way the recipient can obtain the invocation
>>>>identity from the token pointed to by Signature/KeyInfo.
>>>>
>>>>Authentication then becomes a degenerate case of the
>>>>holder-of-key authentication, where the "holder-of-key" is
>>>>now effectively also the assertion authority/ attester.
>>>>
>>>>
>>>>
>>>>From the recipient's perspective the sender-vouches distinction
>>>
>>>
>>>>indicates that the invocation identity is not the signer. In the hk
>>>>case the invocation identity is the signer.
>>>>
>>>>This approach allows one assertion to contain all the
>>>>necessary information, at the expense of 2 signatures
>>>>required by the attester: one to sign the assertion which
>>>>contains the invocation identity as subject of assertion, and
>>>>one to sign the message to bind it to the invocation
>>>>identity. The recipient, by trusting the signing key of the
>>>>attester now simply has to verify 2 signatures which happen
>>>>to be signed by the same signer. In the hk case 2 sigs also
>>>>need to be verified by the recipient by different signers
>>>>chained thru the SubjectConfirmation/KeyInfo. In the sv case
>>>>the chaining is implicit since the attester replaces the
>>>>subject as the signer of the content.
>>>>
>>>>The only loose end in all this I believe is a distinction
>>>>between the attester and the assertion authority. If this
>>>>level is required then we would have another level of
>>>>chaining, whereby we would need subject->attester->assertion
>>>>authority. In this case the assertion authority would need to
>>>>put the attester's key in an hk assertion as the current
>>>>example shows. The attester would then sign the sv assertion
>>>>as described above, and then sign the message. Since we now
>>>>have 3 levels involved, we need the 2nd hk assertion that the
>>>>recipient needs to confirm the attester, assuming the
>>>>recipient ultimately trust the assertion authority.
>>>>
>>>> Rich
>>>>
>>>>-----Original Message-----
>>>>From: Ron Monzillo
>>>>To: Levinson, Richard
>>>>Cc: wss@lists.oasis-open.org
>>>>Sent: 1/30/2004 7:06 PM
>>>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>>>
>>>>
>>>>
>>>>Levinson, Richard wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Replies interspersed below (this discussion gets
>>>>>quite detailed, but I have made a sincere effort to
>>>>>try to stay on point and narrow rather than broaden
>>>>>the scope):
>>>>>
>>>>>Again, I think the bottom line is that using a BST to contain the
>>>>>attester cert in the sender-vouches scenario is a better
>>>>>
>>>>>
>>(cleaner and
>>
>>
>>>>>simpler) option than using a 2nd saml assertion to contain the
>>>>>attester cert.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Rich,
>>>>
>>>>I expect to use sender-vouches approximately as follows:
>>>>
>>>>An attesting entity uses its key binding to secure a message
>>>>containing a request to invoke a web service.
>>>>
>>>>The identity(s) under which the web service is to be invoked
>>>>is represented in the subject statements of the
>>>>sender-vouches confirmed assertion.
>>>>
>>>>The holder of key confirmed security token of the attesting
>>>>entity carries the key used to sign the message, but the
>>>>receiver must be able to recogise that the vouched for
>>>>assertion contains the invocation identity.
>>>>
>>>>Whether or not the key confirmed security token used to sign
>>>>the message and assertion is itself a BST or a SAML
>>>>assertion, has little impact on the message reciever's
>>>>ability to recognize the proper invocation identity for the message.
>>>>
>>>>As the spec is currrently written, it is unclear how the the
>>>>msg receiver can establish the correspondence between the
>>>>SOAP msg and the vouched for subject statments. The only clue
>>>>that the receiver has that such a correspondence should be
>>>>established is the fact that SignedInfo references (i.e.
>>>>digests) a sender-vouches confirmed assertion.
>>>>
>>>>That is my point, and the reason why I suggested that proper
>>>>interpretation of impersonation scenarios, including those
>>>>accomplished using
>>>>sender-vouches
>>>>confirmed assertions could be more direct and consistent with
>>>>how other
>>>>profiles
>>>>establish what I refer to as the invocation identity, if
>>>>Signature/keyInfo (always)
>>>>points to a security token containing the invocation identity. In
>>>>non-impersonation
>>>>scenarios the signer and invocation identities are presumably
>>>>the same.
>>>>
>>>>I included other comments below, but I'd like to focus on the
>>>>representation of impersonation and its interpretation by
>>>>receivers. Sender vouches is on such formulation of which we
>>>>have been dicussing two different approaches; 1 curently in
>>>>the spec, and another based on chaining.
>>>>
>>>>Another form of impersonation would be assertion issuer authorized
>>>>assertion.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>-----Original Message-----
>>>>>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
>>>>>>Sent: Friday, January 30, 2004 12:49 PM
>>>>>>To: Levinson, Richard
>>>>>>Cc: wss@lists.oasis-open.org
>>>>>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>>>>>
>>>>>>
>>>>>>
>>>>>>Levinson, Richard wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Ron,
>>>>>>>
>>>>>>>First I will recount where I think we are in this discussion
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>and what
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>the potential outstanding issues are and then I provide a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>suggestion
>>>>
>>>>
>>>>
>>>>
>>>>>>>for addressing the situation.
>>>>>>>
>>>>>>>(bottom line (to avoid reading all the details): suggestion is to
>>>>>>>have STR2 point to a BinarySecurityToken with the attester cert
>>>>>>>(similar to section 3.3.2 of the X.509 profile, except
>>>>>>>
>>>>>>>
>>in our case
>>
>>
>>>>>>>the sig ref points to the assertion and the sig keyinfo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>points to the
>>>>
>>>>
>>>>
>>>>
>>>>>>>BST):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Rich,
>>>>>>
>>>>>>Unless I am misunderstanding you,
>>>>>>This is what the example in the spec currently does, except STR2
>>>>>>points to a SAML assertion acting as the attester cert,
>>>>>>
>>>>>>
>>and the sig
>>
>>
>>>>>>ref points to the subject assertion and the sig keyinfo points to
>>>>>>STR2, and thus the attester cert. Other than the example
>>>>>>
>>>>>>
>>using only
>>
>>
>>>>>>SAML ST's, I think it analogous to what you propose.
>>>>>>
>>>>>>
>>Maybe you are
>>
>>
>>>>>>focusing on the token combination we should demonstrate
>>>>>>
>>>>>>
>>by interop.
>>
>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Yes, functionally I guess it is equivalent. I was a little confused
>>>>>with the actual "sender-vouches" assertion not being shown
>>>>>
>>>>>
>>>>>
>>>>>
>>>>because it
>>>>
>>>>
>>>>
>>>>
>>>>>is externally accessed, and the on message assertion being
>>>>>holder-of-key. I understand it now but think that readers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>who are not
>>>>
>>>>
>>>>
>>>>
>>>>>intimately familiar with all the options may have
>>>>>
>>>>>
>>difficulty with it.
>>
>>
>>>>>And you are correct that I am focussing on putting together a
>>>>>self-contained scenario for the interop, and I think that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>having the
>>>>
>>>>
>>>>
>>>>
>>>>>signature point to a 2nd saml assertion is not necessary since the
>>>>>recipient is trusting the public key of the
>>>>>
>>>>>
>>signer/attester, not the
>>
>>
>>>>>fact that the public key is obtained in an assertion
>>>>>
>>>>>
>>backed up by a
>>
>>
>>>>>trusted saml authority. My sense is that recipients will probably
>>>>>populate their key stores with certificates from well
>>>>>
>>>>>
>>known issuers
>>
>>
>>>>>rather than self-generated certificates backed up by saml
>>>>>
>>>>>
>>assertions.
>>
>>
>>>>>So, for the interop, I think I am going to go with the
>>>>>BinarySecurityToken as the holder of the attester cert.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I view a SAML holder of key confirmed assertion as an XML
>>>>certificate. The attesting entity could either use ists XML
>>>>certificate or its X509 XSN.1 certficate, they are logically
>>>>equivalent.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>Anyway, I think there is a problem with the existing approach,
>>>>>>especially when STR 2 does not either have a "usage" attribute to
>>>>>>inform the actions of the receiver. Without such a cue,
>>>>>>
>>>>>>
>>The receiver
>>
>>
>>>>>>has to recognize that this is a SAML profile msg, as aposed to an
>>>>>>X509 profile msg, to be able to properly determine the
>>>>>>authentication identity that should be associated with the msg.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>If we use a BinarySecurityToken here, I think things are
>>>>>
>>>>>
>>simplified
>>
>>
>>>>>since there is no ambiguity about identity of the
>>>>>
>>>>>
>>attester. I think
>>
>>
>>>>>the main point of saml sender-vouches is that the attester is
>>>>>vouching for the subject of the saml assertion, and there is not
>>>>>really a need for the attester to also be represented by a saml
>>>>>assertion, and as you have shown that leads to issues regarding
>>>>>whether the requester is depending on the signer of the message or
>>>>>the authority that issued the saml assertion that contains
>>>>>the cert the attester used to sign the message. i.e. it
>>>>>seems to be implicitly forcing a chaining mechanism to
>>>>>be defined for saml assertions similar to certs which is
>>>>>not currently a practice to my knowledge.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I hope I clarified this above, I am interested in being able
>>>>to tell when the invocation identity should be the vouched
>>>>for subject.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>To do this, the receievr has to infer from the fact that a SAML
>>>>>>assertion was signed, and that its confirmation method was
>>>>>>satisfied, that the identity of the signed assertion should be
>>>>>>applied to the msg, as apposed to the identity bound to the
>>>>>>attester's security token; which if refactored as you
>>>>>>
>>>>>>
>>suggest would
>>
>>
>>>>>>be an x509 cert. Such messages will look a lot like conventional
>>>>>>x509 confirmed msgs. The fact that this is an impersonation
>>>>>>scenario is not easy to recognize.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>I'm not sure if I totally follow you here, especially the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>phrase "the
>>>>
>>>>
>>>>
>>>>
>>>>>identity of the signed assertion should be applied to the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>msg". I think
>>>>
>>>>
>>>>
>>>>
>>>>>what you are saying is from the receiver's point of view, who is
>>>>>actually accountable for this message. If that is the
>>>>>
>>>>>
>>case, then the
>>
>>
>>>>>receiver needs to have a way to recognize the attester, and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>this would
>>>>
>>>>
>>>>
>>>>
>>>>>be thru the attester's signing cert, which the receiver
>>>>>
>>>>>
>>>>>
>>>>>
>>>>would have in a
>>>>
>>>>
>>>>
>>>>
>>>>>key store and can be used to verify the signature on the message
>>>>>components. As I indicated above, if this cert is backed by a saml
>>>>>assertion rather than conventional PKI then we have kind of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>a new use
>>>>
>>>>
>>>>
>>>>
>>>>>case that I think is outside of the current scope of
>>>>>
>>>>>
>>common practice
>>
>>
>>>>>even in the saml domain. So, from that point of view I don't
>>>>>
>>>>>
>>>>>
>>>>>
>>>>think we
>>>>
>>>>
>>>>
>>>>
>>>>>would want the attester identity to be defined by the saml
>>>>>
>>>>>
>>assertion
>>
>>
>>>>>but by the attester cert.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>SAML assertions are perhaps a bit more flexible than x509
>>>>identity certs, in that x509 identity certs typically need to
>>>>be long lived; but
>>>>other
>>>>than that, I try to view them as interchangeable. Maybe this
>>>>is an oversimplification on my part.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>> Recount of discussion:
>>>>>>>
>>>>>>>I believe we are in agreement on the "unsigned assertion"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>case where
>>>>
>>>>
>>>>
>>>>
>>>>>>>the attester signs both the assertion and the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>message body
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>and the basis of trust from the receiver perspective is the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>public key
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>of the attester with which the attester may verify the signature
>>>>>>>covering both the body and the assertion and based on the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>recipient's
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>trust in the attester's certificate all the relevant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>information is
>>>>
>>>>
>>>>
>>>>
>>>>>>>trusted.
>>>>>>>
>>>>>>>In addition, in the above case we put the attester's
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>certificate in the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>saml:SubjectConfirmation/saml:SubjectConfirmationData/
>>>>>>>ds:KeyInfo element using the SCD element to contain the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>KeyInfo rather
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>than the SC element which is intended for the subject
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>certificate info.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I was suggesting somnething like what you describe above, leaving
>>>>>>aside for the moment the ConfirmationData vs KeyInfo
>>>>>>
>>>>>>
>>distinction you
>>
>>
>>>>>>have since made, as an alternative to what is ]currently
>>>>>>
>>>>>>
>>being done
>>
>>
>>>>>>in the spec. I don't think we would do both. This is sort of a
>>>>>>backpointer to the cert of the attesting entity, since
>>>>>>the front
>>>>>>pointer in the signature keyinfo is to the attester's cert.
>>>>>>The problem as I see it, is it is difficult for the receiver
>>>>>>to know when to apply SAML token profile semantics, unless
>>>>>>the front pointer points to a SAML assertion.
>>>>>>
>>>>>>At a high level, I was proposing that the KeyInfo
>>>>>>
>>>>>>
>>reference in the
>>
>>
>>>>>>Signature point to a Subject assertion because it would
>>>>>>
>>>>>>
>>make it easy
>>
>>
>>>>>>for the receiver to recognize that the message was signed
>>>>>>
>>>>>>
>>using the
>>
>>
>>>>>>SAML token profile, and that the indended authentication
>>>>>>
>>>>>>
>>entity was
>>
>>
>>>>>>the Subject of the Assertion. This is already how we profile
>>>>>>hold-of-key.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>From my perspective the signature does not need to convey
>>>>any context
>>>>
>>>>
>>>>
>>>>
>>>>>about how the signature should be interpreted. It simply
>>>>>
>>>>>
>>>>>
>>>>>
>>>>signs message
>>>>
>>>>
>>>>
>>>>
>>>>>elements and it is up to the recipient what meaning to
>>>>>
>>>>>
>>attach to the
>>
>>
>>>>>validity of such a signature. The fact that the KeyInfo in the sig
>>>>>leads to a saml assertion as currently in the profile spec
>>>>>
>>>>>
>>does not
>>
>>
>>>>>imply anything about sender-vouches, it is just pointing to a key
>>>>>container. And, in fact, in the profile spec it actually
>>>>>
>>>>>
>>points to a
>>
>>
>>>>>holder-of-key assertion. So, I think that if this points to a
>>>>>BinarySecurityToken instead will not impact any sender-vouches
>>>>>semantics.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The signature is being used to bind an identity to content;
>>>>aka to do data origin authentication. In the sender vouches
>>>>case, it is the vouched for identity that is being bound to
>>>>the content (by the attesting entity).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The sender-vouches semantics comes from the fact that the recipient
>>>>>after verifying the signature determines that one of the
>>>>>
>>>>>
>>references
>>
>>
>>>>>signed by the signature is, in fact, a sender-vouches assertion,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>My point is that it is hard for the receiver to recognize that it is
>>>>expected
>>>>to do this.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>which in the current profile spec is off-message, but once
>>>>>
>>>>>
>>>>>
>>>>>
>>>>obtained by
>>>>
>>>>
>>>>
>>>>
>>>>>the receiver provides the context required to evaluate whether the
>>>>>message should be trusted or not. But the trust in the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>message is not
>>>>
>>>>
>>>>
>>>>
>>>>>due to the fact that there is anything in particular about
>>>>>
>>>>>
>>>>>
>>>>>
>>>>the attester
>>>>
>>>>
>>>>
>>>>
>>>>>contained in the assertion, only the fact that it is a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>sender-vouches
>>>>
>>>>
>>>>
>>>>
>>>>>assertion and that the attester signed it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Actually I would expect the receivr to determine if it trusts
>>>>the attesting entity to vouch for the invocation identity.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Similarly, in the holder-of-key profile, the recipient again
>>>>>
>>>>>
>>>>>
>>>>>
>>>>trusts the
>>>>
>>>>
>>>>
>>>>
>>>>>assertion issuer's signature on the assertion (i.e. it is
>>>>>
>>>>>
>>>>>
>>>>>
>>>>the signer of
>>>>
>>>>
>>>>
>>>>
>>>>>the assertion who is trusted ultimately, not the subject of the
>>>>>assertion) which contains the holder-of-key's certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>which in turn
>>>>
>>>>
>>>>
>>>>
>>>>>is used to verify the message content.
>>>>>
>>>>>Analytically, I believe the holder-of-key scenario
>>>>>
>>>>>
>>>>>
>>>>>
>>>>degenerates to the
>>>>
>>>>
>>>>
>>>>
>>>>>sender-vouches case if the holder-of-key also is the signer of the
>>>>>assertion. Sender-vouches then optimizes this by pulling the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>assertion
>>>>
>>>>
>>>>
>>>>
>>>>>signature out of the assertion and combines it with the
>>>>>
>>>>>
>>content sig.
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Furt2her, I agree that if we apply the same procedure as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>above to the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"signed assertion" case that we would break the signature on the
>>>>>>>assertion, and as you indicate using some kind of transform that
>>>>>>>doesn't include the attester KeyInfo element is probably not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>feasible.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>However, I think the signed assertion case raises some
>>>>>>>
>>>>>>>
>>fundamental
>>
>>
>>>>>>>issues about the basis of trust the receiver has on
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>request. If the
>>>>
>>>>
>>>>
>>>>
>>>>>>>signed assertion is not re-signed by the attester, then the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>recipient
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>effectively must now establish two bases of trust: one with the
>>>>>>>attester and one with the assertion issuer. This may be fine
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>for some
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>use cases, but, in general I think that a recipient
>>>>>>>
>>>>>>>
>>would prefer to
>>
>>
>>>>>>>keep their basis of trust as simple as possible and make one
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>agreement
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>with the attester and let the attester be responsible
>>>>>>>
>>>>>>>
>>for all the
>>
>>
>>>>>>>relevant info in the request.
>>>>>>>
>>>>>>> Here is a suggestion that I think might address all the
>>>>>>> above considerations:
>>>>>>>
>>>>>>>That being said, an alternative means for the attester to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>sign both the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>assertion and the content without breaking the signature on
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>the signed
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>assertion would be to have the STR in the attester's
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Signature/KeyInfo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>element (wsu:Id="STR2") point to a BinarySecurityToken
>>>>>>>
>>>>>>>
>>which would
>>
>>
>>>>>>>contain the attester's certificate used to verify the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>signature. This
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>approach could be used for both the unsigned assertion
>>>>>>>
>>>>>>>
>>and signed
>>
>>
>>>>>>>assertion cases without interfering with the signature if it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>exists on
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>the assertion.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>As noted above, unless I am missing something, and modulo the
>>>>>>substitution of a holder of key confimed assertion for the BST, I
>>>>>>think this is what the sender-vouches example in the spec is
>>>>>>currently demonstrating.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Yes, now that I see the structure with the off message
>>>>>
>>>>>
>>>>>
>>>>>
>>>>sender-vouches
>>>>
>>>>
>>>>
>>>>
>>>>>assertion, they are effectively the same. But as discussed above I
>>>>>think using STR2 to point to a 2nd saml assertion containing the
>>>>>attester's cert is raising some issues that don't appear
>>>>>
>>>>>
>>to me to be
>>
>>
>>>>>critical path for smooth operability. In particular, if it is the
>>>>>attester cert that is ultimately trusted why go to the trouble of
>>>>>wrapping it in a saml assertion? Why not simply use a BST
>>>>>
>>>>>
>>>>>
>>>>>
>>>>and have that
>>>>
>>>>
>>>>
>>>>
>>>>>the end of the trust path?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The SAML assertion is the attester's certificate. In fact, in
>>>>the example we have been discussing, it contains the
>>>>attester's keyValue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I reading back through the thread, and I found a couple of points
>>>>>>that you raised that I think we should call attention to.
>>>>>>
>>>>>>1. As you point out, the SAML Core's description of
>>>>>>
>>>>>>
>>KeyInfo within
>>
>>
>>>>>>SubjectConfirmation; precludes the use of this field to
>>>>>>
>>>>>>
>>specify a a
>>
>>
>>>>>>key held by the attesting entity, not the subject. This
>>>>>>
>>>>>>
>>has come up
>>
>>
>>>>>>before. We need to determine what latitude we have in
>>>>>>
>>>>>>
>>this area. IMO
>>
>>
>>>>>>the SAML spec has been overly prescriptive. I would
>>>>>>
>>>>>>
>>prefer that it
>>
>>
>>>>>>say something like "that specifies a crytographic key held by an
>>>>>>entity authorized to act as the subject.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>As discussed above I think that by using a BST for the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>attester cert we
>>>>
>>>>
>>>>
>>>>
>>>>>can avoid dealing with this issue.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> An XML Signature [XMLSig] element that specifies a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>cryptographic
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> key held by the subject."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>2. You point out that even if an assertion is signed, the
>>>>>>
>>>>>>
>>attesting
>>
>>
>>>>>>entity must sign it. I think you are concerned about the
>>>>>>
>>>>>>
>>case of a
>>
>>
>>>>>>signed sender-vouches confirmed assertion without a contained and
>>>>>>protected key binding. In which case I agree the attesting
>>>>>>entity is defining the key binding, and this
>>>>>>must sign
>>>>>>the asertion and the message content.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>It sounds like we agree there. i.e. a signed assertion in and of
>>>>>itself does not protect anything but itself. In order
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yes, but the issue is whether it embodies an authority protected key
>>>>binding.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>to bind such an assertion to external content, we have
>>>>>2 cases: sender-vouches whereby the attester signs both
>>>>>the assertion and the content, and holder-of-key where the signed
>>>>>assertion contains the holder-of-key's public key or cert
>>>>>
>>>>>
>>and it is
>>
>>
>>>>>the holder-of-key's signature on the content that binds the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>content to
>>>>
>>>>
>>>>
>>>>
>>>>>the assertion thru hk's public key bound in the assertion
>>>>>
>>>>>
>>>>>
>>>>>
>>>>which can be
>>>>
>>>>
>>>>
>>>>
>>>>>used to verify the content signature.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I am not sure how close to being on the same page we are, so I
>>>>>>hesitate to raise another problem, but it seems to me
>>>>>>
>>>>>>
>>that section
>>
>>
>>>>>>3.3.4 of of the WSS STP,
>>>>>>"SAML assertion referenced from SubjectConfirmation" (by STR)
>>>>>>is prone to substitution problems, if the refererences do not
>>>>>>(at least) unambiguouly identify the intended security token.
>>>>>>
>>>>>>We defined the STR Dereference transform to be able to digest
>>>>>>assertion contents when they are referenced by STR, we
>>>>>>
>>>>>>
>>would likely
>>
>>
>>>>>>need to require that a similar transform be applied in the
>>>>>>calculation of the
>>>>>>signatures of assertions with STR's within
>>>>>>SubjectConfirmation/KeyInfo.
>>>>>>
>>>>>>I guess this could be argue against complex key references in
>>>>>>SubjectConfirmtion/KeyInfo.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>As I mentioned in an earlier email my concern with 3.3.4 is that we
>>>>>have a potential infinite loop where the STR in the KeyInfo in the
>>>>>assertion points to the assertion itself, and we never
>>>>>
>>>>>
>>>>>
>>>>>
>>>>actually seem to
>>>>
>>>>
>>>>
>>>>
>>>>>find the key in question.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Maybe this could be a problem.
>>>>
>>>>I am concerned about the substitution properties of KeyInfo
>>>>inside SubjectConfirmation.
>>>>
>>>>Ron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Rich
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Ron
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Rich
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>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.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>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/leav
>>>
>>>
>>e_workgrou
>>
>>
>>>p.php.
>>>
>>>
>>>
>>>
>>>
>
>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.
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]