Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt

[Alejandro Perez Mendez <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab