Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] RequestedAttribute "in the field"

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive


Re: [eduGAIN-discuss] RequestedAttribute "in the field"


Chronological Thread 
  • From: Ian Young <ian AT iay.org.uk>
  • To: Andy Bennett <andyjpb AT knodium.com>
  • Cc: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] RequestedAttribute "in the field"
  • Date: Tue, 17 Jun 2014 09:04:09 +0100
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT iay.org.uk
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>


On 17 Jun 2014, at 08:45, Ian Young <ian AT iay.org.uk> wrote:

> There was some interesting discussion about meta-attributes at the last
> REFEDS meeting which might help with that in the longer term.

Apologies for the fragmented response (bad night on the Caledonian Sleeper)
but the other thing we may want to look at again in the UKf and elsewhere are
the consequences of more widely adopting the compromise we ended up with for
the GÉANT Code of Conduct:

> If the Service Provider supports both SAML 1.x and SAML 2.0 protocols, it
> SHOULD list requested attributes
> using only the SAML 2.0 attribute naming conventions [MACEDirAttrProf].

This isn't a complete solution by any means (you still need something like
the meta-attributes idea to handle the hard cases around identifier choice)
but I'm inclined to think the downsides are becoming less significant as we
get more SAML 2.0 adoption.

-- Ian



Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19.

Top of Page