Skip to Content.
Sympa Menu

md-distro - Re: [md-distro] avoiding dynamic metadata queries

Subject: Metadata Distribution Subcommittee of TAC

List archive

Re: [md-distro] avoiding dynamic metadata queries


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: [md-distro] avoiding dynamic metadata queries
  • Date: Fri, 16 Aug 2013 15:56:34 -0400

On Fri, Aug 16, 2013 at 11:17 AM, Ian Young
<>
wrote:
>
> On 16 Aug 2013, at 13:56, Tom Scavo
> <>
> wrote:
>
>> (Related to this, I suspect eduGAIN is a disaster waiting to happen.)
>
> I think that's probably a bit harsh.

Okay, so I should have said: an MDX server that supports arbitrary "ad
hoc" queries (to use Scott's terminology) is a disaster waiting to
happen. I think we can avoid that and still offer some significant
capability.

>> The MDX syntax
>> is easily extended to entity attributes, so it shouldn't be too hard
>> to let users create entity attributes and thereby pre-register their
>> queries (so that the target aggregate can be pre-computed).
>
> We could probably have a discussion about whether that first statement
> (that such an extension is "easy") is really true. There have been a
> couple of proposals for this, but I've pushed back on them for a couple of
> reasons. One of those is that entity attributes are only a SAML metadata
> concept right now, and the intention is not to tie the metadata query
> protocol to SAML.

At the end of the day, an entity attribute is a name-value pair, so it
really is quite general. Moreover, you can think of an entityID as a
special entity attribute having name:

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

You probably don't like that name (because it has the word "SAML" in
it) but the point is that an entityID is just a distinguished entity
attribute (in the same way a user ID is a distinguished user
attribute).

> The more important reason to push back, though, is that turning everything
> into entity attribute algebra is probably not what you want to do anyway.

I can't speak for anyone else but it definitely *is* what I want to do
since it fits my world view perfectly. That said, I'm not sure it
needs to be represented in the spec at all.

So let me summarize my main points:

- An MDX server can avoid arbitrary "ad hoc" queries and still deliver
significant functionality.
- Can we agree that most everything of interest (> 80%) can be known
in advance and can therefore be pre-computed?
- Let users create entity attributes and thereby pre-register their
queries (so that the target aggregate can be pre-computed).
- An online signing key (secured in a trusted HSM) is a separate
issue. From a security PoV, what we lose by exposing the signing key
in an HSM might be gained by tightening the validity window and
eliminating the human factor.

Comments?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page