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 - 
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.


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

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

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

Attachment: draft-catalyst-interop-plan-01JM.doc
Description: MS-Word document

Attachment: SAMLPushPull.doc
Description: MS-Word document

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

Powered by eList eXpress LLC