OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] Re: Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)

On 11/27/14, 3:13 AM, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:

>I wanted to follow up on this, lest it gets forgotten in the subsequent 
>discussions on the 'multiple value types' thread.

Thank you for the prod, I wanted to clarify my point about the 
front-channel query case.

>First difference: RealMe uses HTTP redirect binding for SP request , 
>whereas Dutch eID is using Artifact Binding.  We use the Artifact binding 
>for the response, I think, because at the time (2005/6) we felt that not 
>enough was known about HTTP POST how to mitigate risks at the SPs, and 
>whether our SPs would do the security job we wanted of them.. :-)  

Yeah, I was going to comment on that, but artifact *to* the IdP is really 
a non-starter. It's unnecessary, and much harder to implement from an SP, 
and has no value. I would certainly advise against it.

>Second difference: From broker to  attribute provider, RealMe uses 
>Attribute Query Profile - looks like Dutch are using something like a 
>websso profile?.  The consent is captured at AP than broker?
>You can see Attribute Query in the spec above.

They're apparently crafting a front-channel use of the attribute query 
profile, which is not formally profiled in SAML, though technically it 
falls out. But it isn't really secure without more work, or at least 
without a lot of implied processing at the recipient, which was the point 
I was raising.

>I don't think we published anything specific on this, but what we did in 
>the end was use HTTP AuthnRequest to put the 'attribute query' in.
>That's OK and there is metadata to support it.

That's the AttributeConsumingServiceIndex thing, but that's not entirely 
equivalent to queries (e.g., it has quite different processing rules, in 
that the IdP isn't obligated to listen). But it's mostly ok.

>But then we got into the static vs dynamic conundrum. So it works fine 
>for a basic use case with one or two  'pre-known' attribute queries.

Thing is, though, the idea that there are lots of other cases has been a 
fantasy. The use cases are exceedingly rare for dynamic. I'm sure they 
exist, but claiming this is a major driver is implausible for me.

>Memory is fading re this, but all I am trying to point out here, is that 
>a browser based request for attribute query is a legitimate option (in 
>support of Scott's comment on the call).

Well, my comment is that it's not. And the reason is that if you add in 
the security features (Audience, Subject Confirmation, short-livedness) 
you want in a front-channel, bearer-delivery model for the assertion 
coming back from the query, you get....Web SSO. It's 99% the same, and 
there's just no point. What you're doing is requesting the Attribute 
Provider authenticate the user, get their data, and get consent. That's 
Web SSO. So why not just use it?

Just because you call it an Attribute Provider, that doesn't mean it's 
important to use an AttributeQuery to talk to it. I don't think it's worth 
the work.

>Happy holidays you folks in the US..which means you should not be reading 
>this! :-)

The alternative is I keep writing documentation, which is worse.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]