RE: [saml-dev] draft-catalyst-interop-plan-01

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Jahan...It appears to me that your Push/Pull model violates the one-time use
semantics of the artifacts.  See cs-sstc-bindings-00 section 4.1.1.6/lines
471-474.  Allowing this reuse seems dangerous.  Or did I misunderstand
something in your design.

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com


> -----Original Message-----
> From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> Sent: Saturday, April 27, 2002 10:03 PM
> To: 'Mishra, Prateek'; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] draft-catalyst-interop-plan-01
> 
> Prateek -
> Thanks for getting this started. I have made some specific
> comments/suggestion via MS tracking which is attached. I have also
> attached a second (1/2 page) document that describes an additional
> "flow" that I think would be very powerful yet easy to demonstrate. I
> did not want to add this to your document because I wasn't sure if the
> level of detail was approproiate. However, please feel free to cut and
> paste if you think it is appropriate.
> 
> In a nutshell, the flow I am porposing will demonstrate a combination of
> push (email) and pull (content provider), with SAML acting as the method
> for securely (and seamlessly) going from one to the other.
> 
> 
> For people who do not like to read the entire attached documents, below
> I proivde the same (redundant) information.
> 
> Thanks,
> Jahan
> 
> 
> >>>>>>>
> 
> Section 1 of your document states:
> 'Some effort will be made to "clothe" the entire demonstration as a
> high-level business flow so as to interest a general technical
> audience."
> 
> **
> I very much like this idea and think that it is essential that we show a
> combination of "push" and "pull", with SAML acting as the method for
> securely and seamlessly going from one to the other. Please see the
> document (SAMLPushPull.doc) for a specific scenario.
> **
> 
> Section 1.2, URL Naming Convention
> **
> What is the difference between the "portal" and the "inter-site
> transfer"? I thought they are one and the same (i.e., the URL for
> browser to go to authenticate and receive the artifact).
> **
> 
> Section 1.3, Portal (NameIdentifier element)
> **
> I strongly support the idea of having email address of the subject as
> the name identifier :-)
> **
> 
> Section 1.4, Content provider
> ***
> This is fine and will work well. However, in Sigaba's model we do not
> have "interesting content". Rather, our assertion consumer would be a
> key server that releases a decryption key for a secure email. The
> decrypted email will be an HTML page with URL(s) to "interesting
> content" (e.g., a bill payment service).  We suggest that subsequent to
> decrypting the email the browser would send the artifact to a second
> assertion consumer, which would allow it to view content and/or
> transact. This is what I mean by saying that we can combine push (email)
> and pull (content provider) into a rather powerful flow (Please see the
> document SAMLPushPull.doc for a suggestion on an additional supported
> flow).
> ***
> 
> Section 1.6.b (trust model)
> **
> I think the correct standard here is PKCS #7 and not PKCS #12.
> **
> 
> *** Suggested Additional Flow for possible inclusion in section 1.5.
> 
> The following scenario demonstrates how SAML can be used to securely
> combine push and pull technologies into a seamless user experience. In
> this flow the same artifact is consumed by two different assertion
> consumers, possibly at two different sites. The specific scenario is
> secure on-line bill presentment and payment.
> 
> A service uses secure email to push an invoice to a user. The invoice is
> formatted as an HTML attachment, with the actual invoice encrypted.
> Subsequently, the following steps are used to demonstrate how SAML can
> be used to view and pay the invoice (How the secure email is generated
> and sent to the user is not in the scope of the demonstration. The
> demonstration starts with the user receiving a secure email.)
> 
> 1.	The user (via a browser) authenticates with the portal and
> receives an artifact.
> 2.	 The browser is redirected to a key server (content provider
> #1). The key server authenticates the user and releases the message
> decryption key.
> 3.	The user views the invoice and clicks on a URL on that invoice.
> The URL takes the user to a payment site (content provider #2) and
> provides the same artifact.
> 4.	The payment site authenticates the user and provides a list of
> invoices the user can pay. Other additional content can also be provided
> depending on the user's attributes (GOLD, SILVER, etc.)
> *****
> 
> 
> ---------------------------
> Jahan Moreh
> Chief Security Architect
> tel: 310.286.3070
> fax: 310.286.3076
> 
> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Friday, April 26, 2002 3:40 PM
> To: saml-dev@lists.oasis-open.org
> Subject: [saml-dev] draft-catalyst-interop-plan-01
> 
> 
> Please comment, I may have missed an existing suggestion or amendment.
> 
> - prateek