Dear all,

we have generated a new version of the draft including the following changes:

 * General editorial work (typo correction and wordsmithing)  on the
   document.
 * Addressing of the editorial comments provided by Troy Shields.
 * Made terminology more consistent with ABFAB. Everything now is
   explained in terms of Clients, RPs, and IdPs.
 * Extended description of the SAML-Message and SAML-Assertion
   attributes (following the typical procedure with the figure and the
   description of each field).
 * Changes to the Privacy and the Security Considerations sections.
 * Changes to the IANA Considerations section dealing with the
   registration of the new attributes.
 * Completed the Acknowledgement section.

Best regards,
Alejandro


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Application Bridging for Federated Access 
Beyond web Working Group of the IETF.

         Title           : A RADIUS Attribute, Binding, Profiles, Name 
Identifier Format, and Confirmation Methods for SAML
         Authors         : Josh Howlett
                           Sam Hartman
                           Alejandro Perez-Mendez
        Filename        : draft-ietf-abfab-aaa-saml-10.txt
        Pages           : 24
        Date            : 2015-02-06

Abstract:
    This document describes the use of the Security Assertion Mark-up
    Language (SAML) with RADIUS in the context of the ABFAB architecture.
    It defines two RADIUS attributes, a SAML binding, a SAML name
    identifier format, two SAML profiles, and two SAML confirmation
    methods.  The RADIUS attributes permit encapsulation of SAML
    assertions and protocol messages within RADIUS, allowing SAML
    entities to communicate using the binding.  The two profiles describe
    the application of this binding for ABFAB authentication and
    assertion query/request, enabling a Relying Party to request
    authentication of, or assertions for, users or machines (Clients).
    These Clients may be named using a NAI name identifier format.
    Finally, the subject confirmation methods allow requests and queries
    to be issued for a previously authenticated user or machine without
    needing to explicitly identify them as the subject.  These artifacts
    have been defined to permit application in AAA scenarios other than
    ABFAB, such as network access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to