[Fim4l] FIM4L guidelines

[Peter Schober]

* 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?

> 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.

> 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.
-peter