Title: Authentication Methods - Proposed changes to core-29
I
would like to keep the reference to the Base64 encoding since otherwise there is
no normative reference in the text (as per a previous editorial
comment).
The following identifiers refer to SAMl-specified
Authentication Methods.
becomes:
The
following identifiers refer to SAML specified Authentication methods. Where
Base64 encoding is specified the data is encoded as specified by [RFC
2045].
-----Original Message-----
From: Hal Lockhart
[mailto:]
Sent: Wednesday, April 03, 2002
10:11 AM
To: 'Philpott, Robert';
Subject: RE:
[security-services] Authentication Methods - Proposed changes to
core-29
I
have no objection to these changes.
Hal
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Wednesday, April 03, 2002
9:11 AM
To:
Subject: RE:
[security-services] 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
