[Fim4l] FIM4L guidelines

[Peter Schober]

Maarten,

You started with scepticism wrt Entity Categories in general:

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

but that seems to be specific to REFEDS R&S -- the only category to
have "optional attributes" so far? And with R&S not being appropriate
for licensed e-resources (i.e., this list) I'm not sure how much we
should go into the details here?

* Maarten Kremers <maarten.kremers at surfnet.nl> [2019-05-17 11:26]:
> 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.

R&S isn't "right" for this list for other reasons, as per above.
Or as per previous discussions (or the draft guidelines) on how little
data is needed/appropriate for library resources, a use-case
completely incompatible with R&S' purpose and implementation.
(CoCo v1 also doesn't have optional attributes, for completeness.)

But the R&S spec even agrees with you that it's not a good fit when
combined with requests for other, /additional/ attributes.

Btw, is your first sentence above ("if an SP request a specific
attribute in the bundle") perhaps missing a negation particle: "if an
SP requests a specific attribute NOT in the bundle"? Your last
sentence ("need more attributes") also seems to support that
assumption? I'll try to answer both ways (literally and with a
missing "not" assumed):

SPs request stuff under R&S via the entity category. Other methods of
signalling are "out of scope" as per the spec. So an IDP claiming
support for R&S must release the R&S attribute bundle to such SPs in
order to be R&S conformant. Simple and no confusion. (The SP may want
more but by definition the R&S spec itself cannot help the SP get
"more than R&S".)

If an SP now /also/ requests a sub-set of the R&S "bundle" attributes
using /other/ methods that's fine for R&S as other methods are still
out of scope as far as R&S is concerned. (And doing that may help with
interop in some limited circumstances.)

It's allowed for R&S SPs to request *additional* attributes (on top of
the R&S attribute bundle) but it's also recommended that they do not
do this:

  "Service Providers [with the R&S category; my addition] SHOULD
  limit their data requirements to the bundle of attributes defined in
  Section 5, but MAY negotiate for additional data as required via
  mechanisms that are outside the scope of this specification."

So if your particular circumstances as such that you have valid
reasons to ignore that SHOULD you're free to ask for more -- but ask
yourself this: If merely asking for attributes using traditional (and
flawed) signalling (RequestedAttribute elements) was sufficient to get
these attributes from IDPs why would we have even defined R&S or CoCo?

So requesting additional attributes on top of the R&S bundle doesn't
make much sense, because you may end up needing to provide additional
justification/motivation to IDPs (such as the Entity Categories our
community has defined, with their respective safegards) in order to
get more data from them.
But that doesn't mean there's any confusion about either of your
cases: To be conformant with R&S you need to do what R&S says you need
to do in order to be conformant (release the R&S bundle to all R&S
SPs). An SP that has both R&S and CoCo categories and has valid
reasons to ask for addtional attributes is free to do so. Still no
confusion.
Finally, an SP with only R&S asking for more than the R&S bundle will
simply find many IDPs unwilling to supply additional attributes w/o
additional justification.

-peter