RE: Authenticator to Subject Confirmation renaming

[George Robert Blakley III <blakley@us.tivoli.com>]

Phill

I'd like to keep SubjectConfirmation instead of just Confirmation,
for purposes of explicitness and ease of understanding.

I would revise your definitions:


Authentication
    The process by which AN AUTHENTICATION ASSERTION ISSUER determines that
the party purporting to be X
     is or is not in fact X where X may be a name  or a psuedonym.

     Authentication is out of scope of SAML, but assertion of
authentication by an authentication assertion issuer
     is in scope

SubjectConfirmation
    The process by which AN ASSERTION'S RELYING PARTY determines that the
party purporting to be
     the assertion's subject is in fact the assertion's subject.

     Subject confirmation is in scope of SAML, and is a means for an
assertion's relying party to determine
     whether the issuer of the assertion has authorized the entity
presenting the assertion to the relying party
     to function as its subject.


--bob

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


"Hallam-Baker, Phillip" <pbaker@verisign.com> on 08/21/2001 03:10:36 PM

Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com>

To:   "'Tim Moses'" <tim.moses@entrust.com>, "Security-Services (E-mail)"
      <security-services@lists.oasis-open.org>
cc:
Subject:  RE: Authenticator to Subject Confirmation renaming




We  discussed that in the call (or to be precise my perception is that we
discussed  it). Unfotch the message with the text went out after the
document went out and  not previously during the call as I intended. I did
catch the bug Carlisle  brought up.

AuthenticationMethod is used in the Authentication  assertion and in the
SubjectConfirmationMethod while Subject ConfirmationData is  only used in
the SubjectConfirmation.

We  could move to simply 'ConfirmationMethod' in both places which I
suspect would  provide better for the Anonymous cases.

Since  confirmation is only something that is possible to a subject we
might want to  move from SubjectConfirmation to simply Confirmation.


I  think that the anonymity discussion is clarified by differentiating
authentication and confirmation.

Authentication
    The process by which we determine  that the party purporting to be X is
or is not in fact X where X may be a name  or a psuedonym.

Confirmation
    The process by which we determine  that the party purporting to be a
member of a set of Y of authorized users is or  is not in fact a member.

    Authentication is one means of  achieving confirmation


             Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal  Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996  x227

-----Original Message-----
From: Tim Moses  [mailto:tim.moses@entrust.com]
Sent: Tuesday, August 21, 2001 2:16  PM
To: Security-Services (E-mail)
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>>