RE: "binding" assertions to business payloads

[Philip Hallam-Baker <pbaker@verisign.com>]

What I should have said is that the output document would be another
purchase order and hence not a SAML auth assertion.

However it could very well be an assertion. The SAML assertion 'container'
would IMNSHO be a usefull building block for that type of message set. The
<Claims> would be different and possibly invclude different <Conditions> but
the basic processing principles could be carried over.

	Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Monday, May 07, 2001 1:23 PM
> To: Philip Hallam-Baker; Heather_Hinton@tivoli.com
> Cc: 'Mishra, Prateek'; ''oasis sstc' ';
> security-bindings@lists.oasis-open.org
> Subject: RE: "binding" assertions to business payloads
> 
> 
> Philip et al,
> 
> 	I agree that Case (1) is a SAML application. But the 
> e-mail said it is out
> of scope which I disagreed. Thanks for clarification.
> 
> > > > Case (1) is out of scope since it is simply another 
> purchase order.
> 
> 	BTW, purchase order is just an example. So dismissing 
> it as a purchase
> order specific is not going to help. The point is, element 
> level (or more
> generally block level) assertions in business documents. As 
> we all know,
> currently there are no "assertions" in business documents, 
> just attributes.
> The assertion, in a very loose manner, is the whole document. 
> Hopefully we
> could evangelize the assertions concept at block level.
> 
> cheers
> 
> > -----Original Message-----
> > From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> > Sent: Monday, May 07, 2001 9:52 AM
> > To: 'Krishna Sankar'; Heather_Hinton@tivoli.com; Philip Hallam-Baker
> > Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> > security-bindings@lists.oasis-open.org
> > Subject: RE: "binding" assertions to business payloads
> >
> >
> > If the application simply obtains a SAML assertion and on that basis
> > re-issues the purchase order with a new sig it is simply a 
> standard SAML
> > application with no need to make special provision. The 
> purchase order
> > specific issues would be dealt with in the purchase order 
> spec - i.e. 'out
> > of SAML scope'.
> >
> > It would only be case 2 that would involve a significantly different
> > application of SAML.
> >
> > Sorry if my phrasing was confusing.
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> > > -----Original Message-----
> > > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > > Sent: Monday, May 07, 2001 12:39 PM
> > > To: Heather_Hinton@tivoli.com; Philip Hallam-Baker
> > > Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> > > security-bindings@lists.oasis-open.org
> > > Subject: RE: "binding" assertions to business payloads
> > >
> > >
> > > Hi all,
> > >
> > > 	As far as I know, RosettaNet is silent on authorization.
> > >
> > > 	The RNO has the signature of the sender which *could*
> > > aid case (2). But
> > > usually the signature (and encryption) is for achieving the
> > > security across
> > > the wire and possibly for non-repudiation and *not* for 
> authorization.
> > >
> > > 	Re Prateek's point, I would say Case (1) is more in
> > > line with our charter.
> > > We could help standards like RosettaNet to add this
> > > capability to "normal"
> > > purchase orders.
> > >
> > > cheers
> > >
> > > > -----Original Message-----
> > > > From: Heather_Hinton@tivoli.com 
> [mailto:Heather_Hinton@tivoli.com]
> > > > Sent: Monday, May 07, 2001 9:19 AM
> > > > To: Philip Hallam-Baker
> > > > Cc: 'Mishra, Prateek'; Philip Hallam-Baker; ''oasis sstc' ';
> > > > 'security-bindings@lists.oasis-open.org'
> > > > Subject: RE: "binding" assertions to business payloads
> > > >
> > > >
> > > > It occurs to me that the example given below is covered by
> > > the RosettaNet
> > > > standards. I will see if I can find anything there that is
> > > of interest. In
> > > > the meantime, check out www.rosettanet.org
> > > >
> > > > heather
> > > >
> > > > Heather Hinton,
> > > > Senior Security Architect
> > > > Tivoli SecureWay
> > > > IBM Corporation
> > > > hhinton@tivoli.com
> > > > (tel) +1(512)436-1538
> > > >
> > > >
> > > > Philip Hallam-Baker <pbaker@verisign.com> on 05/07/2001 
> 10:11:31 AM
> > > >
> > > > To:   "'Mishra, Prateek'" <pmishra@netegrity.com>, Philip
> > > Hallam-Baker
> > > >       <pbaker@verisign.com>, "''oasis sstc' '"
> > > >       <security-services@lists.oasis-open.org>
> > > > cc:   "'security-bindings@lists.oasis-open.org'"
> > > >       <security-bindings@lists.oasis-open.org>
> > > > Subject:  RE: "binding" assertions to business payloads
> > > >
> > > >
> > > >
> > > >
> > > > This type of 'Purchasing workflow' type application
> > > involves pieces that
> > > > are
> > > > out of scope but is definitely important.
> > > >
> > > >
> > > > The way I would see the workflow going is as follows
> > > >
> > > > Alice creates a purchase order
> > > >
> > > > <PO>
> > > >    <Item>Paperclips
> > > >    <Qty>1000
> > > >    <Amount>1,992 USD
> > > > <Signature>
> > > >    <Alice>
> > > >
> > > >
> > > > There are two ways that this PO could then be authorized
> > > >
> > > > 1) Query to see if Alice is Authorized to purchase 1000
> > > paperclips at the
> > > > stated price. This will by necessity involve some complex
> > > policy/business
> > > > logic.
> > > >
> > > > <SAML>
> > > >    ...
> > > >    <Claims>
> > > >       <Subject>
> > > >          [Alice...]
> > > >       <Object>
> > > >          <Resource>[Purchase up to $5000]
> > > >    <Conditions>
> > > >       [Online check she is not overspent]
> > > >
> > > > 2) Alice gets the PO countersigned by a party that has (largely)
> > > > unrestricted signature powers. [Probably a cryptographic
> > > signing unit in a
> > > > secure facility].
> > > >
> > > > At this point what is effectively being created is an
> > > authorized purchase
> > > > order. The Authorization statement then wants to either 1)
> > > restate the
> > > > original 'Alice' purchase order or 2) cryptographically
> > > bind to it, e.g.
> > > > via
> > > > a MAC.
> > > >
> > > > Case (1) is out of scope since it is simply another 
> purchase order.
> > > >
> > > > Case (2) is potentially in scope and certainly merits a proof of
> > > > extendability.
> > > >
> > > > I think the case implies that the <Subject> of the
> > > authorization would be
> > > > the purchase order. The consistent means of specification
> > > would be as a
> > > > link
> > > > with a cryptographic digest - perhaps reusing the XML
> > > signature manifest
> > > > package.
> > > >
> > > > Alternatively since the entire assertion is signed the
> > > Authorization could
> > > > restate the purchase order as an advice element.
> > > >
> > > >      Phill
> > > >
> > > >
> > > >
> > > > Phillip Hallam-Baker FBCS C.Eng.
> > > > Principal Scientist
> > > > VeriSign Inc.
> > > > pbaker@verisign.com
> > > > 781 245 6996 x227
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> > > > > Sent: Sunday, May 06, 2001 9:38 PM
> > > > > To: 'Philip Hallam-Baker '; ''oasis sstc' '
> > > > > Cc: 'security-bindings@lists.oasis-open.org'
> > > > > Subject: "binding" assertions to business payloads
> > > > >
> > > > >
> > > > > One issue discussed in the bindings group con-call
> > > > > this past week is that of providing an authentic 
> binding between
> > > > > assertions and business payloads. The following scenario
> > > > > is driven off use-case 3 from the requirements document:
> > > > >
> > > > > End-user Ravi utilizes an authentication service
> > > > > and obtains assertions ("Ravi is an employee of
> > > > > Company X at the supervisor level")
> > > > > which he packages with a business
> > > > > payload ("Buy 100 paper clips") to create a composite package.
> > > > > One way to ensure authenticity is to have Ravi sign 
> the composite
> > > > > package with his private key. When the recipient receives the
> > > > > package, the recipient can check to see if the package has
> > > > > been tampered with. If not, the recipient can scrutinize the
> > > > > assertions and appropriately process the business payload.
> > > > >
> > > > > The concern here is with a MITM attack: attacker John 
> intercepts
> > > > > the package and packages the assertion with a completely
> > > > > different payload ("Buy 1000 computers"), signs the composite
> > > > > package and forwards it to the recipient.
> > > > >
> > > > > In order to avoid an MITM attack, it seems necessary that the
> > > > > assertion should include Ravi's public key (or more generally
> > > > > <dsig:keyinfo>) within the assertion. When the composite
> > > > > package arrives at the recipient, she can validate
> > > > > the signature using the public key found within the
> > > > > assertion. This ensures that only the
> > > > > original ``holder'' of the assertion could have bound it to
> > > > > the payload.
> > > > >
> > > > > It is not clear to me how this is handled
> > > > > within the current assertion structure. Obviously,
> > > > > this issue is fairly key to the bindings group; some
> > > > > clarification is required in this space.
> > > > >
> > > > >
> > > > > - prateek
> > > > >
> > > > >
> > > > >
> > > > > 
> ------------------------------------------------------------------
> > > > > To unsubscribe from this elist send a message with 
> the single word
> > > > > "unsubscribe" in the body to:
> > > > > security-services-request@lists.oasis-open.org
> > > > >
> > > >
> > > >
> > > > (See attached file: Phillip Hallam-Baker (E-mail).vcf)
> > > >
> > >
> >
> >
>

Phillip Hallam-Baker (E-mail).vcf