OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Prateek - 
The flows proposed to date do accommodate our needs so we can proceed.

That said, I am finalizing our technical specifications for the demo and
am hoping that we can work with other vendors to demonstrate push/pull.
One idea is for other content providers to produce an email (e.g.,
confirmation of some transaction) that gets secured by Sigaba and sent
to a user (i.e., Sigaba will provide the SMTP gateway). The user then
authenticates with the "portal" and decrypts/reads the email. This will
require the participation of our key server as "content provider".

In summary, we are fine with the present flows, though we will have to
think creativly about how we can use it to best demonstrate the
push/pull model.

Thanks,
Jahan


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


> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com] 
> Sent: Friday, May 10, 2002 1:39 PM
> To: 'jmoreh@sigaba.com'; 'Philpott, Robert'; 
> saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] draft-catalyst-interop-plan-01
> 
> 
> Jahan,
> 
> I am preparing the next (and final?) revision of the interop 
> scenario. Based upon the message flows to date, my 
> understanding is that the flows in the interop document 
> accommodate the flows you need (with some minor variation: 
> the content provider is a key server etc.).
> 
> - prateek
> 
> >>-----Original Message-----
> >>From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> >>Sent: Monday, April 29, 2002 6:02 PM
> >>To: 'Philpott, Robert'; saml-dev@lists.oasis-open.org
> >>Subject: RE: [saml-dev] draft-catalyst-interop-plan-01
> >>
> >>
> >>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>
> >>> 
> >>
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC