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] | [Elist Home]


Subject: RE: Authenticator to Subject Confirmation renaming


Title: RE: Authenticator to Subject Confirmation renaming

Bob - The current set of values for SubjectConfirmationMethod can be found in Section 4.1 of Draft Version 0.15.  Best regards.  Tim.

-----Original Message-----
From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
Sent: Tuesday, August 21, 2001 2:36 PM
To: Tim Moses
Cc: Security-Services (E-mail)
Subject: RE: Authenticator to Subject Confirmation renaming


OK, Maybe I'm confused again.

I agree with Tim that in the <SubjectConfirmation> structure:

        <element name="SubjectConfirmation" type
="saml:SubjectConfirmationType"/>
        <complexType name="SubjectConfirmationType">
                <sequence>
                        <element ref="saml:AuthenticationMethod" maxOccurs
="unbounded"/>
                        <element name="SubjectConfirmationData" type
="string" minOccurs="0"/>
                        <element ref="ds:KeyInfo" minOccurs="0"/>
                </sequence>
        </complexType>

The field that's currently called <AuthenticationMethod> should be called
<SubjectConfirmationMethod>,
and it should have values like "None", "HolderOfKey" (in which case the key
data goes in SubjectConfirmationData?), etc...


I understand also what all the fields of <AuthenticationAssertionType> are
for.  What I don't understand is why
there ISN'T a field in this structure called <AuthenticationMethod> (in
addition to AuthenticationInstant and AuthenticationLocale)
to tell the relying party what mechanism the issuer used to authenticate
the subject.  Or should I be looking elsewhere?

In addition, I've got a nit.... I think that in the <Subject> structure,
the order of members should be

     <NameIdentifier>
     <AssertionSpecifier>
     <SubjectConfirmation>

(Because SubjectConfirmation could apply in either case, presuming that
<AssertionSpecifier> is
to cater for the case where the Subject is designated by another assertion,
to which this one refers?
Or maybe I'm wrong here... If we have an AssertionSpecifier, do we assume
that if SubjectConfirmation
is necessary, it's specified in the referenced assertion rather than in the
referencing assertion... now that
I think about it this seems a better model... sorry for rambling)

Finally, I can't work out how <KeyInfo> is intended to be used.

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


Tim Moses <tim.moses@entrust.com> on 08/21/2001 01:15:31 PM

Please respond to Tim Moses <tim.moses@entrust.com>

To:   "Security-Services (E-mail)" <security-services@lists.oasis-open.org>
cc:
Subject:  RE: Authenticator to Subject Confirmation renaming





Phill - I think this reflects the discussion on the call this afternoon.
Except that, to be consistent, we should change "AuthenticationMethod" to
"SubjectConfirmationMethod".

The element that retains the term "authentication" is this one ...

<xsd:complexType name="AuthenticationAssertionType">
 <xsd:complexContent>
  <xsd:extension base="saml:SubjectAssertionAbstractType">
   <xsd:sequence>
    <xsd:element ref="saml:AuthenticationCode"/>
    <xsd:element name="AuthenticationInstant" type="timeInstant"/>
    <xsd:element name="AuthenticationLocale" type
="saml:AuthenticationLocaleType" minOccurs="0"/>
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

All the best.  TIm.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Tuesday, August 21, 2001 2:00 PM
To: Security-Services (E-mail)
Subject: Authenticator to Subject Confirmation renaming

This is the new text:

1.1.1   Element <Subject>
The <Subject> element specifies a party by any of the following means:
        *       A name.
        *       By information that allows the party to be authenticated.
        *       By reference to another assertion or by containment of
another assertion.
If a <Subject> element contains more than one subject specification the
issuer is asserting that all the subject specifications present specify the
same subject. For example if both a <NameIdentifier> and a <Authenticator>
element are present the issuer is asserting that the authentication data
authenticates the party with the specified name.
The following schema defines the <Subject> element:
        <element name="Subject" type="saml:SubjectType"/>
        <complexType name="SubjectType">
                <choice maxOccurs="unbounded">
                        <element ref="saml:NameIdentifier"
                                        minOccurs="0"
maxOccurs="unbounded"/>
                        <element ref="saml:SubjectConfirmation"
                                        minOccurs="0"
maxOccurs="unbounded"/>
                        <element ref="saml:AssertionSpecifier"
                                        minOccurs="0"
maxOccurs="unbounded"/>
                </choice>
        </complexType>
1.1.1.1 Element <SubjectConfirmation>
The <SubjectConfirmation> element specifies a subject by specifying data
that authenticates the subject.
        <AuthenticationMethod>[Any number]
        Each <Authentication> element specifies a URI that identify a
protocol that may be used to authenticate the subject.
        <SubjectConfirmationData>[Optional]
        Each <SubjectConfirmationData> element specifies additional
authentication information used by a specific authentication protocol.
        <ds:KeyInfo>[Optional]
        An XML Signature <ds:KeyInfo>  element that specifies a
cryptographic key held by the subject.
URIs identifying common authentication protocols are specified in Section 4
.
The following schema defines the <SubjectConfirmation> element:
        <element name="SubjectConfirmation"
type="saml:SubjectConfirmationType"/>
        <complexType name="SubjectConfirmationType">
                <sequence>
                        <element ref="saml:AuthenticationMethod"
maxOccurs="unbounded"/>
                        <element name="SubjectConfirmationData"
type="string" minOccurs="0"/>
                        <element ref="ds:KeyInfo" minOccurs="0"/>
                </sequence>
        </complexType>

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227 <<Phillip Hallam-Baker (E-mail).vcf>>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC