RE: [security-services] more metadata questions...

["Scott Cantor" <cantor.2@osu.edu>]

> [RSP] I agree it's an authority role.  But are you saying that to do
> this type of retrieval, you'd use the service defined in the
> <AuthnAuthorityDescriptor>?

That was my thinking, yeah.

> My point is that Web SSO assertions are
> often not the same as assertions that an Authentication Authority would
> create. They might contain both authn statements AND attribute
> statements.  So a web SSO "authority" is really a different type of
> authority.  

There's nothing that says an authn authority can't include attributes
either. There's just not a real fine line between the 3 types, so I was just
trying to avoid clutter and assume that if you're an IdP that also allows
assertion queries, you're acting as one or more of the other three kinds of
roles.

I don't feel that strongly about it.

> [RSP] I agree it's mainly a schema issue and don't feel that strongly
> about it.  The main point was to point out the inability IMO to retrieve
> Web SSO assertions by their ID since they aren't the same as
> authentication assertions.

There is no such thing as a web SSO assertion. That was mentioned earlier in
a comment, and we don't define that term. If anything, it's defined as an
authn assertion delivered via SSO profile, which rules out queries anyway.

> [RSP] Hmmm. I didn't interpret it this way (i.e. intended for the SSO
> case) since a) it seems to have symmetry with the Attribute Authority
> role, which in our product is specifically for general attribute
> queries, and b) the WantAssertionSigned attribute in the
> <AttributeConsumingService> could conflict with the WantAssertionSigned
> attribute in the SPSSODescriptor.  

I can sort of see the conflict, I guess, but as I said, I really felt the
role was entirely about SSO. I didn't see the use case for saying "here's a
query and BTW I'm not going to tell you what I want but you can find out in
my metadata". It was SSO where you couldn't communicate in band very well.

The exception is the signing requirement attribute, I guess, but that was
really something I didn't think deeply about when I added it.

> In our environment, I need to be able to describe whether to sign
> attribute assertions that I send back in response to general attribute
> queries.

Seems like we should have added that to the protocol more than metadata?

> This is what I thought the <AttributeConsumingService> would be
> used for. It's less important to us to have an SP define via metadata
> what attributes it "might" query.  In most cases it might seem odd,
> although it might be useful under certain conditions.  

It's not really for that so much, it's for the IdP to know what attributes
to push over during SSO (i.e. no query). As I said, if you want to query,
the thinking was, just tell it what you want.

> Certainly for Web SSO, we need to be able to have an SP tell us what
> attributes they need our IDP to include in the Web SSO assertions we
> send them (I can't do it in the AuthnRequest and probably wouldn't want
> to do it there anyway).

Right, but with metadata you *can* tell it. You include the consuming
service index in the AuthnRequest. It's a query by reference.

> [RSP] I understand.  But do you see why we actually need settings for
> general query support that are distinct from settings for SSO?

Yes, but I guess my only (slight) push back is, isn't it more useful to just
add the signing requirement to the query protocol directly?
 
> [RSP] True enough.  In my opinion, we should put an SP's 
> desired Web SSO attributes in the SPSSODescriptor role definition
> and make the <AttributeConsumingService> describe settings that a relying 
> party needs when it makes general attribute queries.

I'm not objecting per se. I wouldn't mind hearing other opinions.

-- Scott