[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)
My suggestion was mainly that what they're suggesting doesn't work
unchanged, it's not suitably secure, at least to the level of the existing
standard and the risks it built in mitigations for.
Met vriendelijke groet,
drs. Martijn Kaag
tel +31 (0) 88 01 20 222 | gsm +31 (0) 6 42 94 00 93 | skype martijn.kaag-connectis
On 12/10/14, 5:35 PM, "Martijn Kaag" <martijn.kaag@connectis.nl> wrote:
>You should specify the (requested) subject if you want additional
>attributes from an Attribute Provider. This user previously authenticated
>at the Identity Provider. For this, they currently envision an
>attributequery over a front-end channel (because they need user consent
>per attribute); I understood that your suggestion was to implement this
>as Web SSO instead.
My suggestion was mainly that what they're suggesting doesn't work
unchanged, it's not suitably secure, at least to the level of the existing
standard and the risks it built in mitigations for.
As far as what would need to be done to make SSO work, that apparently
needs more study. The use case of requesting attributes is easy.
Specifying identifiers in some kind of open ended way is a different
problem. In my comments back, I was just being clear about the fact that
SubjectConfirmation is simply NOT an option for that.
It may be that profiling BaseID is the answer. The way subjects are
expressed doesn't have to be a NameID, there's a bucket there in the
schemas that was put there precisely to allow that element to handle more
open-ended requirements.
-- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]