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