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

[Jahan Moreh <jmoreh@sigaba.com>]

Rob - 
> 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. 
Excellent point, you are correct.

That said, I still believe that having a demonstration that can combine
push and pull is very valuable. Even if that means the user has to
re-enter his/her password, it shows that SAML can be used effectively in
both models.

I will correct the application scenario and redistribute.

Thanks,
Jahan
 

---------------------------
Jahan Moreh
Chief Security Architect
tel: 310.286.3070
fax: 310.286.3076


> -----Original Message-----
> From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] 
> Sent: Monday, April 29, 2002 2:43 PM
> To: 'jmoreh@sigaba.com'; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] draft-catalyst-interop-plan-01
> 
> 
> 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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>