I looked at WSS 1.0[1] and section 7.4 seems to describe a mechanism for embedded *any* token type. By my reading of that section, an embedded X509 cert would look something like;
<wsse:SecurityTokenReference>
<wsse:Embedded>
<wsse:BinarySecurityToken ValueType='wsse:X509v3' EncodingType='wsse:Base64Binary' >
...
</wsse:BinarySecuirtyToken>
</wsse:Embedded>
</wsse:SecurityTokenReference>
Gudge
[1] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
> -----Original Message-----
> From: Dittmann, Werner [mailto:]
> Sent: 16 February 2006 00:15
> To: Martin Gudgin; Marc Goodner;
> Subject: AW: [ws-sx] Issue 27: When to include a token?
>
> Some comments inline.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: Martin Gudgin [mailto:]
> > Gesendet: Dienstag, 14. Februar 2006 23:55
> > An: Marc Goodner; Dittmann, Werner;
> > Betreff: RE: [ws-sx] Issue 27: When to include a token?
> >
> > Comments inline
> >
> > Cheers
> >
> > Gudge
> >
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:]
> > > Sent: 09 February 2006 20:43
> > > To: Dittmann, Werner;
> > > Subject: [ws-sx] Issue 27: When to include a token?
> > >
> > > This is now logged as issue 27.
> > >
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/
> > >
> > >
> > > -----Original Message-----
> > > From: Dittmann, Werner [mailto:]
> > > Sent: Thursday, February 09, 2006 12:12 AM
> > > To:
> > > Cc: Marc Goodner
> > > Subject: NEW Issue: When to include a token?
> > >
> > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
> > THREAD UNTIL
> > > THE ISSUE IS ASSIGNED A NUMBER.
> > >
> > > The issues coordinators will notify the list when that
> has occurred.
> > >
> > > Protocol: ws-sp
> > > ws-securitypolicy-1.2-spec-ed-01-r03-diff.pdf
> > >
> > > Artifact: spec
> > >
> > > Type: design
> > >
> > > Title: When to include a token?
> > >
> > > Description:
> > >
> > > Using token inclusion values (chap 5.1.1) one can specify when to
> > > include a token. On the other hand in chap 5.3.3
> X509Token Assertion
> > > there are ways defined how to reference a X509 token. For example
> > > if "RequireIssuerSerialReference" is set and the
> inclusion value is
> > > "always": shall the token be included in the message? Which token
> > > shall the receipient take - the included one or the referenced?
> >
> > [MJG]
> > I believe that inclusion requirements and reference requirements are
> > orthogonal. In your example above, I would expect the X509
> cert to be
> > carried in the message and for its IssuerSerial to match that in the
> > IssuerSerial in any referencing STR.
>
> [WD]
> CAn agree. However, we had such a use case during some discussions on
> the WS Security list (and we actually had code in place that provided
> such a mechanism) but somehow the discussion showed that this usage
> should be avoided (can't remember the reasons for it, it's
> about 1 year
> ago).
>
> > >
> > > With respect to the WS Security specification I interpret the
> > > inclusion value "always*" or "once" without any additional
> > "Require*"
> > > assertion as "include the token as a BinarySecurityToken
> > and reference
> > > it using a Reference in the SecruityTokenReference". Is
> > this a correct
> > > interpretation?
> >
> > [MJG]
> > Include the token in the message and reference it using a Direct
> > Reference from the STR (e.g. reference to a wsu:Id in the
> case of, for
> > example, a Username token ).
> >
> > >
> > > Also, with respect to WSS how to interpret or act on the
> > > RequireEmbeddedRefernce assertion? WSS does not specify an
> > "embedded"
> > > mechanism for X509 certificates.
> >
> > [MJG]
> > I thought embedded was defined as the token appearing
> verbatim inside
> > wsse:Embedded inside wsse:SecurityTokenReference but
> perhaps my memory
> > is faulty.
> >
> [WD] Yes, some time ago in the first draft specs of WS
> Security there was
> an identifier for such a behaviour. The current versions
> don't support that
> any more, AFAIK.
>
> > >
> > > Related issues:
> > > none
> > >
> > > Proposed Resolution:
> > >
> > > Clarify behaviour of the "token inclusion" and "token reference"
> > > interworking to avoid misinterpretations and probable interop
> > > problems.
> > >
> > >
> > > Werner Dittmann
> > > Siemens COM MN CC BD TO
> > > mailto:
> > > Tel: +49(0)89 636 50265
> > > Mobil: +49(0)172 85 85 245
> > >
> >
>
