Metadata Distribution Subcommittee of TAC

["Cantor, Scott" <>]

On 9/6/13 8:43 PM, "Tom Scavo" 
<>
 wrote:
>
>Define "everything." All CMU entities (~300). All Duke entities
>(~1100)? I mean, seriously, I'm not sure I want to go down that path.

Then we're not talking about the same model at all. I freely admit that I
have no understanding of why anybody would register those SPs into
InCommon, I would never do that here. But having done it, you shouldn't
have to treat them any differently, and it's disruptive to the goal of
moving away from batches to do so.

What is the limiting factor here? Because I'm not getting it. This is a
scripted or online operation, and if it's too slow to do in batch at some
point, then I think it needs to be done online. But I really doubt it's
going to be too slow any time soon.

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

People rarely configure web servers to assign a different expiration time
to every resource, they make generalizations. I don't expect federations
would be any different.

The other point is that using cacheDuration allows the distribution point
to provide a basic policy hint to the code instead of telling people to
configure that hint on their end as a setting. That means you can change
the hint based on experience or operational changes without having to
touch every endpoint. So I would say even with a regular offline signing
process, there's an advantage to providing a value.

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

I really don't know what it should be. I would have thought more like 3-4
given what I tend to do with the InCommon metadata now, but whatever it
is, I'm saying we can send it in-band and essentially remotely configure
the behavior.

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

No, I didn't mean it was a literal transform (my example was more of a
joke about how naive the old thinking was), I just mean you have to be
able to map it. I would not have the expectation that the actual entityID
had to contain that domain, even if that's the normal case.

In practice, it probably means reverse mapping Scope in the majority of
cases, allowing for some exceptions because not all Scopes have to map
1:1, but that's purely speculation.

-- Scott