Subject: [abfab] Fwd: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt

From: Alejandro Pérez Méndez <[email-masked]>
Date: Mon, 5 Oct 2015 09:32:58 +0200

Dear all,

we have submitted a new draft called " Retrieving remote attributes 
using GSS-API naming extensions" that aims to describe how current 
GSS-API extensions can be used to allow mechanisms to retrieve remote 
attributes without requiring of any change neither on the existing calls 
nor on the way applications use the API.

Any comment or feedback is welcome.

Regards,
Alejandro

-------- Mensaje reenviado --------
Asunto: 	New Version Notification for 
draft-perez-abfab-gss-remote-attr-00.txt
Fecha: 	Mon, 05 Oct 2015 00:27:18 -0700
De: 	[email-masked]
Para: 	Alejandro Perez-Mendez <[email-masked]>, Alejandro Perez-Mendez 
<[email-masked]>, Rafa Marin-Lopez <[email-masked]>, Rafael Lopez <[email-masked]>, 
Gabriel Lopez-Millan <[email-masked]>, Gabriel Lopez-Millan <[email-masked]>

A new version of I-D, draft-perez-abfab-gss-remote-attr-00.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-perez-abfab-gss-remote-attr
Revision:	00
Title:		Retrieving remote attributes using GSS-API naming extensions
Document date:	2015-10-05
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-perez-abfab-gss-remote-attr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perez-abfab-gss-remote-attr/
Htmlized:       https://tools.ietf.org/html/draft-perez-abfab-gss-remote-attr-00

Abstract:
    The GSS-API Naming Extensions define new APIs that extend the GSS-API
    naming model to support name attribute transfer between GSS-API
    peers.  Historically, this set of functions has been used to obtain
    the authorization information contained in some sort of authorization
    token provided to the GSS acceptor during the context establishment
    process, such as a Kerberos ticket, a SAML assertion, or an X.509
    attribute certificate.  However, some scenarios require to allow the
    GSS acceptor to request additional attributes after context
    establishment.  If these attributes are not locally stored by the GSS
    mechanism they have to be retrieved from an external source (e.g.
    SQL database, LDAP directory, external IdP, etc.).  This document
    describes how current GSS-API extensions are able to encompass such
    functionality without requiring of any change, neither on the
    existing calls nor on the way applications use the API.

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.

The IETF Secretariat

---

From: Alex Stuart <[email-masked]>
Date: Mon, 5 Oct 2015 10:10:42 +0100

Hi Alejandro

I think some names of the SAML attributes have got swapped. In section
5.1, the last bullet point should be:

* urn:ietf:params:gss:federated-saml-attribute
urn:oasis:names:tc:SAML:2.0:attrname-format:uri
urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonEntitlement attribute)

And in 5.6, the parenthetical SAML eduPersonAffiliation and SAML
eduPersonEntitlement should be swapped.

However, I'm not sure that an application would first receive an
entitlement, then ask for an affiliation. Because affiliation has a
small controlled vocabulary and entitlement can be as fine-grained as
you like, I think the logic would be reversed. I can envisage that an
application receives affiliation, which it finds too coarse to allow
authorization, and then looks for entitlement to make the decision.

Regards,
Alex

On 05/10/2015 08:32, Alejandro Pérez Méndez wrote:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
> 

-- 
Alex Stuart
Team Leader - Federated Access Management
EDINA, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Mon, 5 Oct 2015 11:30:34 +0200

> eduPersonEntitlement should be swapped.

Hi Alex,

yup, you are right. I will change it for the next version.

> authorization, and then looks for entitlement to make the decision.

It was just an example, so I didn't think so much how much sense it made 
:).
But since your example seems more logical, I will borrow it and use it 
for the next version. Thanks!

Regards,
Alejandro