Skip to Content.
Sympa Menu

md-distro - Re: [md-distro] verifying what I heard on this week's call

Subject: Metadata Distribution Subcommittee of TAC

List archive

Re: [md-distro] verifying what I heard on this week's call


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: [md-distro] verifying what I heard on this week's call
  • Date: Fri, 6 Sep 2013 20:43:17 -0400

On Fri, Sep 6, 2013 at 7:47 PM, Cantor, Scott
<>
wrote:
> On 9/6/13 5:06 PM, "Tom Scavo"
> <>
> wrote:
>
>>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.

Define "everything." All CMU entities (~300). All Duke entities
(~1100)? I mean, seriously, I'm not sure I want to go down that path.

>>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.

How should I know? I have absolutely no expectations with respect to
any single entity descriptor. You can't expect the federation to know
the answer to that question. Only the metadata owner will have any
clue at all.

> 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.

No, I didn't say that. Today, a finely tuned metadata client will
issue a request for an aggregate every hour. Barely 4% of those
requests will result in actual metadata. For per-entity metadata, the
client had still better make a request every hour (to limit their
vulnerability window) but the percentage of requests that actually
result in metadata content is miniscule. For many entities,
essentially zero, and in some cases, *precisely* zero (since their
original submission will never change).

> validUntil is a very different thing again, since that controls the actual
> revocation.

Right. With my FedOp hat on, I think an optimal value of validUtil is 4 days.

> 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.

So are you saying that cacheDuration is one hour?

>>Finally, I have no idea what discovery looks like in a world of
>>per-entity metadata. Anybody care to speculate about that?
>
> ... you get a domain, you map it to an entityID, you fetch the
> metadata and you go.

For IdPs this might work since we're pretty fussy about the entityID
being rooted in the IdP's primary domain. This is yet another reason
to strongly enforce that policy.
Tom



Archive powered by MHonArc 2.6.16.

Top of Page