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:
> -----Original Message-----
> From: Jahan Moreh [mailto:]
> Sent: Saturday, April 27, 2002 10:03 PM
> To: 'Mishra, Prateek';
> 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:]
> Sent: Friday, April 26, 2002 3:40 PM
> To:
> Subject: [saml-dev] draft-catalyst-interop-plan-01
>
>
> Please comment, I may have missed an existing suggestion or amendment.
>
> - prateek
