<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Nick,</p>
<p>this is IMO a very good idea and was my first thought when I
heard that RA21 supports Coco, which version ever. An entity
category for commercial publisher's offerings would be a much
better way to specify respective attribute release policy.</p>
<p>@all: Entity categories allow for configuring release policies
per group of services instead of per individual Service Provider.
<br>
</p>
<p>Cheers,</p>
<p>Peter G.<br>
</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">> If you think this is a mistake you can provide your input into the
> amendment process that will likely begin soon for an R&S "2.0" spec,
> but as it stands the R&S spec and FIM4L use-cases have zero overlap.
</pre>
<pre class="moz-quote-pre" wrap="">This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.
Best Regards,
Nick
</pre>
</blockquote>
<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 09.04.19 um 23:02 schrieb Nick Roy:<br>
</div>
<blockquote type="cite"
cite="mid:6153E95D-B0BC-422F-B285-5694048765EC@internet2.edu">
<pre class="moz-quote-pre" wrap="">
On 9 Apr 2019, at 9:04, Peter Schober wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">* Jiri Pavlik <a class="moz-txt-link-rfc2396E" href="mailto:jiri.pavlik@mzk.cz"><jiri.pavlik@mzk.cz></a> [2019-04-09 14:28]:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Do you find eduPersonEntitlement or eduPersonScopedAffiliation attribute
better fit for authorisation when faculty, institute students and employee
need to be recognised according to license terms?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Some SPs only support one (when talking about authorisation and
entitlements I mean the "common-lib-terms" attribute value
specifically), some can support both (with configuration; personally
I'd wish the SPs would just check for one and then fall back to the
other!), some may only support affiliations.
That's the status quo which is therefore more complex than necessary,
IMO -- at least as long as we're talking about institution-level
licensing. (For anything more fine-grained than that both
ePE=common-lib-terms and <a class="moz-txt-link-abbreviated" href="mailto:ePSA=whatever@example.edu">ePSA=whatever@example.edu</a> are equally
unsuited, as we've established earlier. So /that/ specific use-case
would still need agreement and standardisation, AFAICT.)
I think I've made the case here previously that the "common-lib-terms"
ePE value has the big advantage of being invariant and the same from
every IDP and for every SP (for the use-case it's been defined for),
whereas eduPersonScopedAffiliation handling usually requires bilateral
negotiations between the institution and the e-resource provider
(sometimes via a self-service web UI, sometimes by filling out
spreadsheets with data that's already contained in the SAML Metadata
of the federation, etc.)
So for the same use-case ePE has clear advantages.
ePE with the "common-lib-terms" value is less common in some very
large federations, though, e.g. within the UKfederation. That matters
because effecting change there would mean having to convince
potentially hundreds of service provider to change.
(As long as those service providers also checked for
the "common-lib-terms" ePE first and fell back to their current use of
ePSA everything should "just work" for most every institution.)
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">However eduPersonEntitlement is missing in R&S attribute bundle.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That is irrelevant as the REFEDS Research & Scholarship specification
explicitly states that it "should not be used for access to licensed
content such as e-journals." ([1], Section 1, "Definition").
If you think this is a mistake you can provide your input into the
amendment process that will likely begin soon for an R&S "2.0" spec,
but as it stands the R&S spec and FIM4L use-cases have zero overlap.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.
Best Regards,
Nick
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
-peter
[1] <a class="moz-txt-link-freetext" href="https://refeds.org/category/research-and-scholarship">https://refeds.org/category/research-and-scholarship</a>
_______________________________________________
FIM4L mailing list
<a class="moz-txt-link-abbreviated" href="mailto:FIM4L@lists.daasi.de">FIM4L@lists.daasi.de</a>
<a class="moz-txt-link-freetext" href="http://lists.daasi.de/listinfo/fim4l">http://lists.daasi.de/listinfo/fim4l</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
FIM4L mailing list
<a class="moz-txt-link-abbreviated" href="mailto:FIM4L@lists.daasi.de">FIM4L@lists.daasi.de</a>
<a class="moz-txt-link-freetext" href="http://lists.daasi.de/listinfo/fim4l">http://lists.daasi.de/listinfo/fim4l</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>