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:]
> Sent: Monday, April 29, 2002 2:43 PM
> To: '';
> 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:
>
>
> > -----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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
