[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] SAML core editors: an item to put into do c
Simon, I understand the intent of this extension but I would like to point out that this has not actually been voted on for inclusion in the document. Here are some questions: what does it mean to have a URI included in an assertion? Does it mean that the URI implements a generic SAML responder? Or is it the case that the URI implements a SAML query-response service as embodied in a specified SAML binding? If we are basically dealing with URIs that act as a SAML responder, why do we need to differentiate between three types of "AuthorityKind" ? - prateek -----Original Message----- From: Simon Godik To: 'security-services@lists.oasis-open.org' Sent: 12/21/01 7:25 PM Subject: [security-services] SAML core editors: an item to put into doc Quoted from RL 'Bob' Morgan message: "On the Tuesday 2001-12-18 call there was discussion about process for changes to the spec documents that were approved in concept at the November F2F, but which were awaiting text for completion. We decided that, now that text has been offered for these (and not having been commented on by anyone), that this text should be included in the documents by the editors, leaving to anyone opposed to this text to complain about it afterwards. The point is to close these issues promptly so we can proceed to last call the documents in January as planned." Here is my item. I included modifications made by Scott Cantor in the text. Editors, please update core document. Attribute Authority info in Authentication Assertion was discussed at f2f #5 and clarifying text was requested so that committee can vote on the issue. original proposal was sent out on Monday, October 22, 2001 10:22AM Context here is that Authentication Authority can front several Attribute Authorities as in the case of Shibboleth. Authentication Authority should be able to point to the correct Attribute Authority for authenticated subject by including information about Attribute Authority in AuthenticationAssertion. Proposed text: SAML assumes that given authentication assertion relying party can find attribute authority for the authenticated subject. In a more dynamic situation Authentication Authority can be placed in front of a number of Attribute Authorities. In this case Authentication Authority may want to direct relying parties to the specific Attribute Authorities at the time when authentication assertion is issued. AuthorityBinding element specifies the type of authority (authentication, attribute, authorization) and points to it via URI. AuthenticationStatementType contains optional list of AuthorityBinding's. All AuthorityBinding's in the list must be of the 'attribute' type. Any authority pointed to by the AuthorityBinding list may be queried by the relying party. <element name="AuthorityBinding" type="saml:AuthorityBindingType"/> <complexType name="AuthorityBindingType"> <attribute name="AuthorityKind"> <simpleType> <restriction base="string"> <enumeration value="authentication"/> <enumeration value="attribute"/> <enumeration value="authorization"/> </restriction> </simpleType> </attribute> <attribute name="Binding" type="anyURI"/> </complexType> <element name="AuthenticationStatement" type="saml:AuthenticationStatementType"/> <complexType name="AuthenticationStatementType"> <complexContent> <extension base="saml:SubjectStatementAbstractType"> <sequence> <element ref="saml:AuthenticationLocality" minOccurs="0"/> <element ref="saml:AuthorityBinding" minOccurs="0" maxOccurs="unbounded" <--- addition </sequence> <attribute name="AuthenticationMethod" type="anyURI"/> <attribute name="AuthenticationInstant" type="dateTime"/> </extension> </complexContent> </complexType> Simon Godik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC