Security considerations

[hvdsomp]

Do we need something along the lines of the security considerations of https://tools.ietf.org/html/rfc6596

[zimeon]

I note connection to #2 -- the less actionable the identifying URI is the less likely it is that an agent would be able to verify correspondence with the actual/context/access URI

[hvdsomp]

Very much agreed. But then again, as I indicated in #2 I don't think we can spec something like verifying "correspondence" because in some use cases there is no such thing.

[zimeon]

Here is some possible text to help us think about this issue:

A site might use the identifier link relation with inaccurate or misleading information about the URI to be used for reference. In many cases there will be no way automatically verify the correctness of the identifying URI so out-of-band mechanisms might be required to establish trust.

If a trusted site is compromised, the identifier link relation could be used with malicious intent to supply misleading URIs for persistent referencing. Use of these links might direct users an attacker's site, break the referencing record they are intended to support, or corrupt algorithmic interpretation of referencing data.

[hvdsomp]

Thanks a lot. Will use it in the next iteration. The formulation is a bit doomsday-ish but overall accurate, I think.

[phonedude]

In some cases we can expect to find bi-directional links, right? Publisher/IR --> DOI, and DOI redirects to Publisher/IR. Can we express that bi-directional linkage should increase confidence?

[hvdsomp]

Good point. Bi-directional links would exists in Scenario 3.3, Could exist in Scenario 3.2, and exist in Scenario 3.1 by means of redirects.

So, rather than trying the "correspondence" of content between link context and link target discussed earlier by @zimeon , the existence of a connection (i.e. link, redirect) back from the link target to the link context could be used for verification. Of course, if the link context site has been compromised this doesn't help either.

[zimeon]

My sense is that there is no security concern in the case that an agent can verify the relation by following resolution of the identifying URI to the access URI. I had tried to capture the idea that the concerns section is about other situations through the text "In many cases there will be no way automatically verify the correctness..." but one could soften that perhaps to something like "In cases where there is no way automatically verify the correctness..."?

[hvdsomp]

I have taken "follow-your-nose" feedback from @phonedude and @zimeon into account. Changes are visible in the Security Considerations section (paragraph removed) and the Identifier Relation Type section (paragraph added).

[zimeon]

The use of "trusted site" in the revised security section is somewhat hanging after removal of the first paragraph but perhaps this is OK to get a first draft out, perhaps revisit down the road

[hvdsomp]

Do you think it would be better for this sentence (now in the Identifier Relation section) to move to Security Considerations:

In cases where there is no way for the agent to automatically verify the correctness of the identifying URI, out-of-band mechanisms might be required to establish trust.

and turn it into:

In cases where there is no way for the agent to automatically verify the correctness of the identifying URI (cf Section Identifier Relation type), out-of-band mechanisms might be required to establish trust.

[zimeon]

Yes, I think your revised sentence in the security considerations section would tie things together better.

[hvdsomp]

OK. I will change. It will be next because I'm on vacation now.

Cheers

Herbert

On Jul 17, 2017, at 16:24, Simeon Warner notifications@github.com wrote:

Yes, I think your revised sentence in the security considerations section would tie things together better.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hvdsomp]

Made the change recommended by @zimeon. So closing this issue now.