Interfederation

[Tom Scavo <>]

On Tue, Feb 26, 2013 at 2:19 PM, Scott Koranda 
<>
 wrote:
>
> 1) Since I am requesting that InCommon produce a new metadata feed
> that it has never produced before, is it the case then that use of
> this metadata feed and expectations of the feed are not bound by any
> existing InCommon legal or contractual obligations?

I don't know. What are the "legal or contractual obligations" for the
*current* feed? (I really don't know the answer to that question.)

> My naive expectation is that the answer is 'yes', but it would be good
> to have it clarified.

Well, I can say this: the intended use and expectations of the current
feed are different than the intended use and expectations of the new
feed we've been discussing. I'm hoping that's obvious to folks.

> 2) To my mind the InCommon key used to sign the current InCommon
> metadata aggregate is nothing more than a mechanism to make sure that
> the metadata bits arrive without corruption (from any mechanism) from
> the InCommon server to my SP (or other consumer).

Sure, okay.

> Any and all trust about the current feed is not bound to "the key"
> used to sign that metadata. The trust is codified in other places and
> other ways (I can read and sign various documents) and then the key
> and the signature of the metadata is only a way for me to be sure as
> an SP operator that I am trusting the right set of bits.

Well, we all know you're a rational, well-informed, technical kind of
guy, so clearly you get it, but:

- Unlike you, an alarmingly large number of people don't get it (or so I 
claim).
- You're assuming there are documents you can read to determine your
level of trust, but if there are such documents, I know for sure I
didn't write them, so I can't say if they are accurate.
- The signing key is bound to an X.509 certificate, which confuses the
heck out of people.

> So to my mind there is no need to have a new key that would be used to
> sign a new InCommon metadata aggregate. I simply need to be sure as an
> SP operator that I understand what sets of bits I am getting (what URL
> I am fetching from) and that the bits once I get them have not been
> corrupted.

I don't see a question in there, so I'll just accept your statement as is.

> So my question is, does InCommon Ops view the signing key differently
> or is it, as I have thought, just a mechanism to make sure a set of
> bits get correctly from one place to another?

I should probably start signing my email messages with "the opinions
expressed herein are mine alone," but here goes:

- One metadata file is not enough; at least two metadata files will be
needed. I'm sure some people will want their very own metadata file so
I'm not ruling that out either.

- The two metadata files will have different "intended uses and
expectations," as suggested above. I'm not convinced that two files at
different locations is sufficient to drive home that point. Two sets
of supporting documents are certainly required but I don't think that
will be sufficient to distinguish between the two files either.

- One or more *new* metadata signing keys may be in our future. The
current key is bound to a certificate that expires in one year.
Something has to be done about that.

- The current signing key is associated with a very tight production
pipeline, with very strong protections. (It is an offline signing
key.) We don't want to disrupt that secure pipeline.

I think I'll stop there for now.

Tom