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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Multi-participant transactional workflows

Folks-- I did my action item to ask Ron about the issue with 
multi-participant transactional workflows, and here is his response.


-------- Original Message --------
Subject: Re: SAML TC question: multi-participant transactional workflows
Date: Wed, 23 Jul 2003 17:05:21 -0400
From: Ron Monzillo <ronald.monzillo@sun.com>
To: Eve L. Maler <eve.maler@sun.com>
References: <3F1EEC9C.2020204@sun.com>

Eve L. Maler wrote:

> In yesterday's telecon we went over our list of candidate work items 
> for V2.0, and there was one that caused your name to come up: 
> "profiles for multi-participant transactional workflows".  Here is the 
> whole exchange as recorded in the minutes 
> (http://lists.oasis-open.org/archives/security-services/200307/msg00048.html): 
>     - Profiles for multi-participant transactional workflows
>         - Irving: guessing that this is for attaching assertions to
>           workflows
>         - characteristic of web browser profile is that assertions have
>           confirmation methods that render the assertions useless in
>           any other step of a workflow process (which is intentional)

I thought the browser profile relied on the SenderVouches confirmation
method, and that such assertions are "bearer tokens"; which means they
may be used downstream of the web server/servlet container.
I thought it was only the artifact that was single use.

The (WSS) SAML token profile describes the use of SAML assertions with the
SenderVouches confirmation method, and leaves open the possibility for the
SenderVouches confirmation method to identify a confirmation key. My
understanding is that some folks would like to use this form of assertion to
enable a form of transparent impersonation, where the sender and the subject
are different,  and the sender must be able to demonstrate knowledge of the
confirmation key to impersonate the subject.

So I probably am not understanding something, but it would seem that
assertions acquired by te browser profile could be used in a subsequent

>         - Prateek: Irving for champion here?
>         - Irving: wouldn't be right person
>         - [ACTION] Eve to send Ron Monzillo question on profiles for
>           multi-participant transactional workflows
>         - Scott: may also be a possible champion
>         - basically doesn't think our assertions should be short-lived
> In the call, though it wasn't captured, someone asked a question here 
> about how J2EE could be made to allow for passing through of SAML 
> assertions. 

There has been some interest in defining another CSIv2/IIOP identity
token form
to accomodate SAML (SenderVouches) authentication assertions. CSIv2 defined
an extensibility mechanisms to facilitate the integration of new
Identity token forms.

There is also interest in using SAML assertions via the SAML profile of
WSS to
authenticate SOAP msgs fro2m intermediates to downstream web services. This
can be done with SenderVouches assertions (with or without a Subject
key) or with HolderOfKey Assertions where the key of the intermediate is
in the


> If you get to this before your vacation, great; if not, don't worry 
> about it.  Thanks, and have a wonderful time away from all this!
>     Eve

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com

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