[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [saml-dev] InterOp Scenario Extensions draft-01
Not sure. Andrew do you want to follow through with this ? As I indicated
earlier, Sun would probably be able to support this proposed scenario, but it
all depends on how many other vendors would like to participate in
this extension.
Thanks
Bhavna
>From: "Mishra, Prateek" <pmishra@netegrity.com>
>To: "'Andy Fetterer'" <afetterer@crosslogix.com>, "'Bhavna Bhatnagar'"
<bhavna.bhatnagar@Sun.COM>, [email protected]
>Subject: RE: [saml-dev] InterOp Scenario Extensions draft-01
>Date: Fri, 10 May 2002 17:58:44 -0400
>MIME-Version: 1.0
>
>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:afetterer@crosslogix.com]
>Sent: Thursday, May 09, 2002 12:56 PM
>To: 'Bhavna Bhatnagar'; saml-dev@lists.oasis-open.org; 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:bhavna.bhatnagar@sun.com
><mailto:bhavna.bhatnagar@sun.com> ]
>Sent: Thursday, May 09, 2002 8:49 AM
>To: saml-dev@lists.oasis-open.org; [email protected]
>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 <afetterer@crosslogix.com>
>>Subject: [saml-dev]
>>To: saml-dev@lists.oasis-open.org
>>MIME-version: 1.0
>>List-Owner: < mailto:saml-dev-help@lists.oasis-open.org
><mailto:saml-dev-help@lists.oasis-open.org> >
>>List-Post: < mailto:saml-dev@lists.oasis-open.org
><mailto:saml-dev@lists.oasis-open.org> >
>>List-Subscribe: < http://lists.oasis-open.org/ob/adm.pl
><http://lists.oasis-open.org/ob/adm.pl> >,
>< mailto:saml-dev-request@lists.oasis-open.org?body=subscribe
><mailto:saml-dev-request@lists.oasis-open.org?body=subscribe> >
>>List-Unsubscribe: < http://lists.oasis-open.org/ob/adm.pl
><http://lists.oasis-open.org/ob/adm.pl> >,
>< mailto:saml-dev-request@lists.oasis-open.org?body=unsubscribe
><mailto:saml-dev-request@lists.oasis-open.org?body=unsubscribe> >
>>List-Archive: < http://lists.oasis-open.org/archives/saml-dev/
><http://lists.oasis-open.org/archives/saml-dev/> >
>>List-Help: < http://lists.oasis-open.org/elists/admin.shtml
><http://lists.oasis-open.org/elists/admin.shtml> >,
>< mailto:saml-dev-request@lists.oasis-open.org?body=help
><mailto:saml-dev-request@lists.oasis-open.org?body=help> >
>>List-Id: <saml-dev.lists.oasis-open.org>
>>
>
>________________________________________________________________________
>Bhavna Bhatnagar Sun Microsystems Inc.
>
>Identity Management group __o
>Tel: 408-276-3591 _`\<,_
> (*)/ (*)
> ________________________________________________________________________
>
>
________________________________________________________________________
Bhavna Bhatnagar Sun Microsystems Inc.
Identity Management group __o
Tel: 408-276-3591 _`\<,_
(*)/ (*)
________________________________________________________________________
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC