RE: [security-services] Authentication Methods - Proposed changes tocore-29

Title: Authentication Methods - Proposed changes to core-29

> *replace
line 620 with: 

> -- 

> references identifying
SAML-defined confirmation methods are listed in [SAMLBind]. 

> --

 

Since new profiles will be described in
separate documents, would it be useful to say something like:

"URI references identifying
SAML-defined confirmation methods are currently defined with the SAML profiles in
[SAMLBind]. Additional SAML confirmation methods may be defined in future OASIS-approved
SAML profile specifications".

 

Similar text may be needed for the replacement
text for lines 1549-1560.

 

Other than that, I concur with the
proposed changes.

 

I don't remember from the call -
Prateek, will you be sending proposed text changes to add the confirmation
methods to the Bindings doc?

 

Rob
Philpott

RSA Security Inc.

The Most Trusted Name in
e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020

mailto:

 

-----Original Message-----

From: Hal Lockhart
[mailto:] 

Sent: Tuesday, April
 02, 2002 6:28 PM

To:


Subject: [security-services]
Authentication Methods - Proposed changes to core-29

 

*replace
lines 240-242 with: 

--

For example, the SAML-defined
identifier for the password authentication method is as follows: 

urn:oasis:names:tc:SAML:1.0:am:password

-- 

*line
248: change "confirmation" to "authentication"

*replace
line 620 with: 

--

references identifying SAML-defined
confirmation methods are listed in [SAMLBind]. 

-- 

*replace
lines 1533-1534 with: 

--

7.1 Authentication Method
Identifiers 

-- 

*replace
lines 1536-1537 with: 

--

different functions within the SAML
architecture, although both can refer to the same underlying mechanisms.
<AuthenticationMethod>is a part of an Authentication Statement, which
describes an

--

*line
1546: change "will usually" to "may" 

*replace
lines 1549-1560 with: 

--

Subject Confirmation Methods are
defined in the SAML Profile or Profiles in which they are used[SAMLBind].
Additional methods may be added by defining new profiles or by private
agreement.

The
following identifiers refer to SAMl-specified Authentication Methods.

-- 

*delete
lines 1561-1577 

*replace
line 1578-1583 with: 

--

7.1.1 Password 

URI:
urn:oasis:names:tc:SAML:1.0:am:password 

The
authentication was performed by using a password. 

-- 

*delete
lines 1584-1589 

*Replace
line 1590 with: 

--

7.1.2 Kerberos 

-- 

*line
1593: replace "subject is authenticated" to "authentication was
performed" 

*after
line 1594 insert: 

--

7.1.3 X.509 Public Key

URI:
urn:oasis:names:tc:SAML:1.0:am:X509-PKI 

The
authentication was performed by some (unspecified) X.509 PKI mechanism. It may
have been one of the mechanisms for which a more specific identifier has been
defined below.

7.1.4 PGP
Public Key 

URI:
urn:oasis:names:tc:SAML:1.0:am:PGP 

The
authentication was performed by some (unspecified) PGP mechanism. It may have
been one of the mechanisms for which a more specific identifier has been
defined below.

7.1.5
SPKI Public Key 

URI:
urn:oasis:names:tc:SAML:1.0:am:SPKI 

The
authentication was performed by some (unspecified) SPKI mechanism. It may have
been one of the mechanisms for which a more specific identifier has been
defined below.

--

*replace
line 1595 with: 

--

7.1.6 SSL/TLS Certificate-based
Client Authentication 

-- 

  

*replace line 1597 with:

The
authentication was performed using either the SSL or TLS protocol utilizing
client certificates. TLS is described in [RFC 2246].

--

*delete
lines 1598-1621 

*replace
lines 1622-1626 with: 

--

7.1.7 XML Digital Signature

URI:
urn:ietf:rfc:3075 

The
authentication was performed by means of an XML digital signature [RFC 3075].

-- 

 

===============

Note:

I don't
feel that strongly about including PGP and SPKI, but XML dsig supports them so
it seemed most consistent to include them. Alternatively we could just have a
single generic Public Key identifier.

Hal