Metadata Distribution Subcommittee of TAC

["Cantor, Scott" <>]

On 9/6/13 5:06 PM, "Tom Scavo" 
<>
 wrote:

>On the call, I thought I heard Scott say that the current Shib SP
>supports per-entity metadata whereas the IdP does not. Is that
>correct?

Yes. The IdP plugin written by somebody else is on the Contributions page.
For experimental use, I'm sure it's fine.

>If that's true, then it seems the immediate goal would be to provide
>signed per-IdP metadata via md-query. That's good because 1) there are
>*many* SPs in InCommon metadata, and 2) only a small percentage of
>them need to be individually signed and packaged. For example, most of
>the 272 CMU SPs do not need to be exposed as signed, per-SP metadata.
>I suspect there are many such SPs in metadata. Maybe *most* of them.

That I basically understand for a prototype, but as a strategy, no. Once
you offer the ability to query, you offer it, and that's that. DNS does
not decide which hosts to resolve, if one is registered it resolves.

>We probably want to use entity attributes to denote the set of SP
>entity descriptors that do (or do not) need to be signed and exposed
>via md-query, but I'm not even sure where to begin...

Don't agree, at all. You're overthinking this. If you don't think you can
sign everything, then that says to me we need an online key.

>At this point, I'm still pretty confused about the use of validUntil
>and cacheDuration at the per-entity level. I'm not sure why we would
>want to do anything different than we do now (i.e., validUntil only).
>Won't HTTP Conditional GET tell the metadata client everything it
>needs to know?

No, they are not the same. Telling me my current request is for something
with no changes from my last attempt is totally different from
cacheDuration, which tells me when I should expect to ask again. If you're
suggesting the SP just ask every time, no, it doesn't do that. We're not
adding an online network call to a federation for every login.

validUntil is a very different thing again, since that controls the actual
revocation. An online service really needs to provide both attributes and
HTTP cache tags. They all serve as different controls, and properly
written consumers use all three.

But as I said on the call, the notion of cacheDuration really applies only
to a real time oracle. In essence, if you sign in advance, you aren't real
time. So really it's more like having "many batches", and we probably do
just rely on a preconfigured cache duration on the consumer, which the SP
handles via a minCacheDuration setting, just like we do now for batch
loading, with a minReload setting.

>There may be an advantage to elevating HTTP Conditional GET to the
>SAML layer. Wouldn't the MDRPI creationInstant XML attribute serve
>that purpose?

This isn't about conditional GET, it's akin to DNS' TTL. Very different.
DNS doesn't have conditionals because it's just UDP and the packets are
small.

>Finally, I have no idea what discovery looks like in a world of
>per-entity metadata. Anybody care to speculate about that?

Well, first you have all the SPs that don't do discovery, which you would
agree is the majority case. So, nothing changes.

But for the rest, it's purely speculation, and I can only point to
Moonshot, and eduroam. Tell me how they work. If they don't, then I guess
nobody has told them yet.

Less snarky, you get a domain, you map it to an entityID, you fetch the
metadata and you go. Or more complex, you get a domain, you look up a
record in DNS and you go. The latter is of course questionable in light of
the lockdown on DNS at most campuses, same reason we aren't using DNS in
other ways.

A humorous example: back when the code was first done, it was supposed to
be possible to map a domain input into an entityID using a regular
expression, and I used the example of prefixing it with urn:mace:incommon.
Works for OSU ;)

-- Scott