Title: RE: [saml-dev] InterOp Scenario Extensions draft-01
Is there
closure on the proposed scenario? I am not sure
I follow
exactly what is being proposed here. A re-spin would
be helpful, I
could then add it to the official demo. doc.
-
prateek
-----Original Message-----
From: Andy Fetterer
[mailto:]
Sent: Thursday, May 09, 2002 12:56
PM
To: 'Bhavna Bhatnagar'; ; Andy
Fetterer
Subject: RE: [saml-dev] InterOp Scenario Extensions
draft-01
Bhavna / Scott -
Thanks for reviewing the document and making
suggestions.
In terms of how the attribute assertion is passed to the
authorization authority, would the third proposal make the most sense? I
don't think that the expiration range would have to be unreasonably
long.
I intended for the attribute to be required as part of the
authorization query (e.g. the receiver must be able to process it), but its
use in determining the response to the query was not required. My
concern was that not all authorization authorities would be able to support
external attributes but I agree that we the requirement I wrote can be
strengthened.
That being said, should we require that the attribute be used
in evaluation or not pass the attribute as part of the query? I would
prefer to use the attribute since it presents a stronger demonstration of
interoperability between systems but would like to hear from the sub-group
working on the authorization queries.
-Andrew
-----Original Message-----
From:
Bhavna Bhatnagar [mailto:]
Sent: Thursday, May 09, 2002 8:49 AM
To: ;
Subject: Re: [saml-dev]
Andrew,
Thanks for writing this up. I
have a few comments/suggestions embedded. Not sure
if
all can access the doc, since I edited it in staroffice. Here is
the text I have embedded:
AS part of
the original specification by prateek what comes as the SSO Assertion
during SSO has an authentication statement and the
attribute statement holding
the MembershipLevel
attribute. Since there is no separate attribute assertion
coming down as part of the SSO, one would have to either:
1.Make an attribute query to the AA, and on receving the
attribute assertion,
use that as Evidence when making
the proposed Authz query. ( this does not make
sense
since the receiver of the SSO assertion already has the attribute
information)
2. Create an
attribute assertion from the attribute statement received as part
of the SSO Assertion and use that as Evidence. ( dont
think this is SOAP binding
though, someone please
confirm)
3.Use the same SSO Assertion as received
during the SSO, which also holds the
attribute
statement as the Evidence, but then this may have expired. We could
keep the expiration range to be long enough so that
the assertion is alive for
the whole round trip
demo.
If its upto vendor to use/not use the attribute assertion,
what's the point of
making it ?
We need to refine this part to choose one of the 3 options or
any other
alternatives. I think option 3 is more
viable.
Thoughts ?
Thanks
Bhavna
>Content-return: allowed
>Date:
Wed, 08 May 2002 12:43:56 -0700
>From: Andy
Fetterer <>
>Subject:
[saml-dev]
>To:
>MIME-version:
1.0
>List-Owner: <mailto:>
>List-Post: <mailto:>
>List-Subscribe: <http://lists.oasis-open.org/ob/adm.pl>,
<mailto:?body=subscribe>
>List-Unsubscribe: <http://lists.oasis-open.org/ob/adm.pl>,
<mailto:?body=unsubscribe>
>List-Archive: <http://lists.oasis-open.org/archives/saml-dev/>
>List-Help: <http://lists.oasis-open.org/elists/admin.shtml>,
<mailto:?body=help>
>List-Id: <saml-dev.lists.oasis-open.org>
>
________________________________________________________________________
Bhavna
Bhatnagar
Sun Microsystems Inc.
Identity Management group
__o
Tel:
408-276-3591
_`\<,_
(*)/ (*)
________________________________________________________________________
