RE: Authenticator to Subject Confirmation renaming

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

I'm happy with the redefinition within the scope of SAML, however I was
trying to establish the term independently first :-)

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


> -----Original Message-----
> From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
> Sent: Tuesday, August 21, 2001 4:30 PM
> To: Hallam-Baker, Phillip
> Cc: 'Tim Moses'; Security-Services (E-mail)
> Subject: RE: Authenticator to Subject Confirmation renaming
> 
> 
> 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>>
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Phillip Hallam-Baker (E-mail).vcf