Refeds


Subject Fwd: [refeds-attribute-release] some (personal) comments on proposed REFEDS R&S definition
From Nicole Harris <harris@xxxxxxxxxx>
Date Tue, 28 Oct 2014 16:57:51 +0100

Forwarding this to the refeds list.  Please note, only comments
received on the main REFEDS list will be considered part of this
process.

I'd like to take this time to remind people of the person of this last
week window of consultation.  It is only intended to highlight any
complete show-stoppers or glaring errors.  Substantive changes to text
should have been submitted during the formal consultation window.  I
appreciate that people want to get this right, but there has to be a
process or we will never get this signed-off.

Please see inline below.


---------- Forwarded message ----------
From: Steven Carmody <steven_carmody@xxxxxxxxx>
Date: 28 October 2014 15:54
Subject: [refeds-attribute-release] some (personal) comments on
proposed REFEDS R&S definition
To: "refeds-attribute-release@xxxxxxxxxx" <refeds-attribute-release@xxxxxxxxxx>


Hi,

This seems to be in the final steps of the process. Since we seem to
have addressed many of the larger issues, I'm now reading this looking
for the tiny spaces where there may be potential confusion. To loosely
quote Ian -- "being explicit helps the conversation".

1) The definition document is accompanied by an FAQ. It should be easy
to find out that there is an FAQ (which offers further explanation of
some of the phrasing) when you are reading the definition. I think the
FAQ is helpful to people new to R&S; I don't think they'd find the
FAQ, or even think it exists, unless we help them.

I don't see this as an issue.

2) Definition -- paragraph 2 includes some examples of services that
could qualify for R&S. I'd suggest explicitly mentioning using PII to
implement access control. This is implied, but should be made
explicit.

We will not be taking any changes to definition at this stage, these
should have been highlighted during the consultation phase.

3) Definition -- "should not be used for access to licensed content"
-- I think the definition should be explicit about the principle; I
think the principle is "should not be used by (commercial?) services
which require only Affiliation values" ?


We will not be taking any changes to definition at this stage, these
should have been highlighted during the consultation phase.


4) Semantics -- "The Service Provider will not use attributes released
for purposes that fall outside of the R&S definition."

I think we could safely remove the word "released".

I don't see the value of this change.

I think we should have an FAQ entry that provides help in
understanding this sentence. Yes, I know, that's a rathole. But, we
should be able to develop some general guidelines.

This can be done.


5) Registration Criteria -- "The service enhances the research and
scholarship activities of some subset of the registrar's user
community."

I can imagine that a service might be used solely/primarily by people
in other federations, and I think we should allow that. I know its a
stretch. But, I don't think limiting this to the "registrar's user
community" provides any value. The only use case I can think of is
large equipment (radio telescopes?) located in remote places for
geographic reasons but, perhaps, not used (very much, if at all) by
people who are members of the local Federation.

I think you are misreading / over-interpreting this.  If a regsitrar
is tagging an entity it is inevitable that this entity will be
relevant to their user community.

6) Attribute Release -- "For the purposes of access control, a
non-reassigned persistent identifier is required. If your deployment
of eduPersonPrincipalName is non-reassigned, it will suffice.
Otherwise you MUST release eduPersonTargetedID (which is
non-reassigned by definition) in addition to eduPersonPrincipalName.
In any case, release of both identifiers is RECOMMENDED."

If an SP receives BOTH values, how would it know whether or not the
Asserting IDP might re-assign EPPN values ? Should we suggest an
algorithm to SP operators to help decide which value to use ?

I think it is clear that EPPN should only be released if it is not
reassigned.  The presence of TargetedID does not alter this.

7) Could services that primarily support instruction but could also be
used by researchers qualify for R&S ? I think the FAQ should offer
some thoughts.

These are decisions for federations to make and discuss as we get this
deployed.  I'd like to actually get to a place where we can get this
deployed.  Please give us a chance to get there!

8) Could a commercial service requiring a contract qualify for the R&S
tag ? I think the FAQ should offer some thoughts.

This has been covered.