Maarten,
You started with scepticism wrt Entity Categories in general:
* Maarten Kremers maarten.kremers@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@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