interfed - [inc-interfed] questions to InCommon Ops (John and Tom)
Subject: Interfederation
List archive
- From: Scott Koranda <>
- To:
- Subject: [inc-interfed] questions to InCommon Ops (John and Tom)
- Date: Tue, 26 Feb 2013 13:19:11 -0600
- Authentication-results: sfpop-ironport01.merit.edu; dkim=pass (signature verified)
Hi,
Thanks for the dialogue during the call today. It leads me to these
two questions which I am directing at InCommon Ops (John and Tom), but
of course I welcome input from anybody:
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?
My naive expectation is that the answer is 'yes', but it would be good
to have it clarified.
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).
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.
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.
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?
Thanks,
Scott K
- [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] MDRPI, Ian Young, 02/27/2013
- Re: [inc-interfed] MDRPI, Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
Archive powered by MHonArc 2.6.16.