[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