Shepherd writeup

ISE write-up for: draft-draft-young-entity-category-07

  "This document describes a SAML entity attribute which can be used to
   assign category membership semantics to an entity, and a second
   attribute for use in claiming interoperation with or support for
   entities in such categories.
     This document is a product of the Research and Education Federations
   (REFEDS) Working Group process."

Back in 2014 the question "should we consider creating new RFC Streams"
was discussed.  We decided that was not necessary, instead such drafts
could be handled in the Independent Stream.  This document is the first
submitted by an 'outside' group.

This draft has no requests for IANA.

It was reviewed for me by Tom Taylor (a GEN-ART reviewer), Craig Partridge,
Jim Schaad and Eliot Lear.

The authors have responded to the changes suggested by the reviewers,
and also made changes requested by the ISE.  I believe this draft is now
ready for publication.

- - - - - - -

Tom Taylor's review (October 2014):

Document: draft-young-entity-category-02
Reviewer: Tom Taylor
Review Date:  8/10/2014
Deadline:    31/10/2014

Summary: Close to ready, with minor issues.

Major issues:

Minor issues:

Remarks (1)-(3) also apply with applicable changes to Sections 4.1-4.2.

(1) The way in which multiple categories are associated with a SAML entity is not stated explicitly in Section 3.1. Is this done by one Attribute per category or by putting multiple AttributeValues into the same Attribute? Section 3.2 implies the latter, but the syntax should be clarified.

(2) Quoting a paragraph late in Section 3.2:

   If significant changes are made to a category definition, the new
   version of the category SHOULD be represented by a different category

This makes me very uneasy from an interoperability point of view. One could get unexpected results from conflating two versions of the same category. I assume the Working Group's intention was to let the category authority decide the issue.

(3) Quoting the next paragraph in Section 3.2:

   Entity category attribute value URIs MUST be treated as opaque

The document does not say for what purpose they have to be so treated. Obviously not for resolution (mentioned earlier). Please add some text on this.

Nits/editorial comments:

- - - - - - -

Craig Partridge's review (May 2015):

I did a quick read and rapidly realized I was out of my depths -- this
is heavy on syntax and URI rules.  So treat this review as very weak (useful
only if others with domain expertise chime in).

As I read the document, what it does can be summarized as it defines an
entity, to wit:

  The presence of the entity category attribute within an entity's
  entity attributes represents a series of claims (one for each
  attribute value) that the entity is a member of the named categories.

And everything else in the 7 odd pages is simply syntax and straightforward
security considerations around creating an "entity" category.

As someone who is not deep into this topic, the thing I most wanted and
*did not find* was the answer to this question:

  Why is an entity category useful? [Put more bluntly, OK, so I can make
  claims that the entity is a member of the named categories -- why does
  any program or person or web search engine find this useful?  Does it
  replace/augment existing categories or is there a specific gap in
  the semantic space that the concept of an entity fills?]

- - - - - - -

Jim Schaad's Comment (May 2015):

I have read through this document several times and I see no problems with
publishing it.

While I am not a huge SAML expert, I am familiar with most of the concepts
as I have needed to deal with it in other contexts.

- - - - - - -

Eliot Lear's review (Sep 2016):

First a meta-issue.

Another standards organization is making use of the ISE in a way that I
do not believe is entirely intended or reliable for their purposes.  You
retain ultimate authority as to whether to publish a document, and they
should not in any way come to believe that you will do so just because
their process is complete (thus, this review ;-).  My point is that
someone should caution them about this.

Ok, more substantive:

What is being proposed are two things:  An entity category attribute and
an entity category support attribute.  Essentially what they're saying
is "this entity can support the following capabilities or services or is
authorized to do so".  It may be self-asserted or asserted by some
anchor of trust.

This is worthy of publication, but I'd suggest that there is more work

However, while *I* understand the motivation, because I have the exact
same issue with draft-ietf-opsawg-mud but at a bit lower level, I don't
think others will.  They need to motivate the work better.

Also, while I appreciate that breaking up naming governance might make
the problem more digestible, in this first document, I would suggest
that issue requires some real consideration now.  In particular, there
need to be at least some basic rules of the road about which URIs to use
so that there is interoperability.  For instance, semantic changes are
made to group membership?  Is there a versioning mechanism in the URI?

And this brings us back to my first point.  As this is the output of
some other group, if you bring to their attention these two questions
you can assert that you have final authority over the stream.

- - - - - - -