[Fim4l] FIM4L guidelines

Maarten Kremers maarten.kremers at surfnet.nl
Fri May 17 11:25:56 CEST 2019


Hi,

> On 15 May 2019, at 16:37, Peter Schober <peter.schober at UNIVIE.AC.AT> wrote:
> 
> * Maarten Kremers <maarten.kremers at surfnet.nl> [2019-05-15 15:57]:
>> Another issue in my opinion with trust marks / entity categories and
>> mixin it with optional attributes is the possibility of confusion.  
>> 
>> E.g. the R&S category (as mentioned not applicable for publisher in
>> its current version) release a fixed attribute bundle (no more and
>> no less) with an optional element of affiliation. 
>> 
>> To my view this can create confusion in implementations, as the tag
>> itself defines what bundle has to be released and (thus) the
>> required attributes in the request should be ignored, however (as an
>> exception to the exception) the optional attribute of affiliation
>> should be released.
> 
> Well, for R&S the signal what data to release simply is specified to
> be a different one that we were used to: the Entity Attribute/Category
> signals attribute requirements because RequestedAttribute elements
> alone cannot signal more complex requirements (e.g. most requirements
> relating to more than one attribute, such as acceptable alternatives).
> 
> Nothing stops you from /also/ expressing the requirements from the R&S
> spec in other ways incl. the traditionally (and slightly flawed) way
> of using RequestedAttribute elements. In fact doing so may help with
> SAML implementations that do not support Entity Attributes.
> This is even called out in section 5 of R&S:
> 
>  "The use of the <md:RequestedAttribute> mechanism supported by SAML
>  metadata is outside the scope of this category, and may co-exist
>  with it in deployments as desired, subject to this specification’s
>  requirements being met."
> 
> Then there's nothing to ignore and no "exception to an exception" to
> be made?

No, but it does created potential noise if an SP request a specific attribute in the bundle. Which is something you can’t prevent, but gives in potential a lot different ways on how an IdP and SP interpret this and thus something you don’t want do IMHO. Yes it might be more restrictive, but if you need more attributes, using R&S category isn’t the right label in my opinion.

> 
>> Though the idea behind makes sense, it is prone to implementation
>> errors and thus usablitiy.
> 
> In the beginning, when the concept of using Entity Attributes to
> signal an application's requirements was new, there was some
> confusion, esp how IDPs should deal with SPs having multiple different
> Entity Categories (R&S and CoCo, really). But this soon turned out to
> be no issues at all: You satisfy each category's requirements
> individually (or you don't) -- which is the very reason why I've
> expressed concerns each time the idea of a "negative" category (one
> that should not help enable attribute release, but prevent it) came
> up.
> But now I've created an action item for myself trying to find out
> whether we can actually make that work technically. And then of course
> it would also need to be done in a way that's somewhat easy to
> understand or at least to follow.

Looking forward to the outcome. 

> 
>> I noticed Peter S wrote the R&S FAQ, so i’m curious to his view on
>> this in general (and possibly to the R&S example in particular)
> 
> I don't remember doing such a thing. If you're referring to v1 of that
> wiki page here
> https://wiki.refeds.org/pages/viewpreviousversions.action?pageId=1606212
> I guess it may be because I've helped move it from the old TERENA
> wiki, or something like that? Not that I disagree with anything that's
> written there (I should better look at it, though, since it has been
> years since I did) only that I cannot claim credit for doing that.

:-) 


-Maarten

> -peter
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l



More information about the FIM4L mailing list