[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] error in wss-v1.1-spec-cs-SAMLTokenProfile 3.5.2.3 and3.5.2.4 examples
Greg Whitehead wrote: > Ok, I finally understand -- thanks for your patience. I do think > that, for an example in the sender-vouches section of the document, > this construction is more confusing that it needs to be. Even just > including the referenced sender-vouches assertion as an exhibit would > probably help to clarify things. > Greg thanks for the careful review, and I agree that it would have helped to demonstrate sender-vouches confirmation without the use of the transform. If I we get anotehr crack at it, I'll segregate the use of the transform into a separate example; which will make the existing example more explicit. Ron > Thanks, > > -Greg > > On Feb 27, 2006, at 11:00 AM, Ron Monzillo wrote: > >> Greg Whitehead wrote: >> >>> I think now I'm even more confused now. >>> >>> Isn't this section supposed to show how one would use a sender- >>> vouches assertion? I guess it's fine to show use of a holder-of- >>> key assertion to sign the message, but wouldn't the sender- >>> vouches assertion need to be included if it's in play? Otherwise, >>> this is just a holder-of-key example. >> >> >> It is included in that it is signed info by reference >> >> <ds:Reference URI="#STR1"> >> <Transforms> >> <ds:Transform >> Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis- >> 200401-wss-soap-message-security-1.0#STR-Transform"> >> <wsse:TransformationParameters> >> <ds:CanonicalizationMethod >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> >> </wsse:TransformationParameters> >> </ds:Transform> >> </Transforms> >> <ds:DigestMethod >> Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> >> <ds:DigestValue>...</ds:DigestValue> >> </ds:Reference> >> >> for a sender-vouches assertion to be "used" according to the profile >> it must be bound >> by the attesting entity to the vouched for message content (so that >> the receiver...). >> >> A signature over the message content and the vouched for assertion >> is one way >> (i.e., the typical way) to accomplish this. >> >> In the example the key identified in the hok assertion is used by >> the attesting entity to sign what is >> being attested for - in this case the sender-vouches assertion and >> the associated msg content - >> thus the composition in the example. >> >> the use of the hok assertion to provide the signing key is not the >> focus of the example. >> >> Ron >> >>> >>> -Greg >>> >>> On Feb 27, 2006, at 8:01 AM, Ron Monzillo wrote: >>> >>>> Greg Whitehead wrote: >>>> >>>>> These sections are supposed to show examples of the sender- >>>>> vouches subject confirmation method, but the assertions in the >>>>> examples are holder-of-key. >>>>> >>>>> -Greg >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail. You may a link to this group and all your >>>>> TCs in OASIS >>>>> at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/ >>>>> my_workgroups.php >>>> >>>> >>>> >>>> Hi Greg, >>>> >>>> The attesting entity signed the sender-vouches assertion using a >>>> key identified >>>> by a (second) hok assertion. The hok assertion is in the msg. The >>>> sender-vouches >>>> assertion is not in the msg. >>>> >>>> The example is an all-saml formulation. The second assertion >>>> could have been >>>> an x509 certificate or a kerberos service ticket (for example) - >>>> and the signing ket could >>>> also have been conveyed by reference. >>>> >>>> How this clarifies things, and thanks, >>>> >>>> Ron >>>> >>>>> >>>>> 3.5.2.3 Example V1.1 >>>>> The following example illustrates an attesting entity’s use of >>>>> the sender-vouches subject confirmation >>>>> method with an associated <ds:Signature> element to establish >>>>> its identity and to assert that it has >>>>> sent the message body on behalf of the subject(s) of the V1.1 >>>>> assertion referenced by “STR1”. >>>>> The assertion referenced by “STR1” is not included in the >>>>> message. “STR1” is referenced by >>>>> <ds:Reference> from <ds:SignedInfo>. The ds:Reference> includes >>>>> the STR-transform to >>>>> cause the assertion, not the <SecurityTokenReference> to be >>>>> included in the digest calculation. >>>>> “STR1” includes a <saml:AuthorityBinding> element that utilizes >>>>> the remote assertion referencing >>>>> technique depicted in the example of section 3.3.3. >>>>> The SAML V1.1 assertion embedded in the header and referenced by >>>>> “STR2” from <ds:KeyInfo> >>>>> corresponds to the attesting entity. The private key >>>>> corresponding to the public confirmation key occurring >>>>> in the assertion is used to sign together the message body and >>>>> assertion referenced by “STRI”. >>>> >>>> >>>> >>>> >>>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]