[WG-IdP-Selection] TR: [KI-LC] Kantara Workshop at RSA
philippe...@orange-ftgroup.com
Trent Adams proposes during a slot in RSA (March 1st) to have a short presentation of each WG and respective work.
I've drafted a few slides, could you please react if these ones seem to you enough (or not) representative of what we are trying to achieve ?
Kind regards,
Philippe
-----Message d'origine-----
De : lc-bo...@kantarainitiative.org [mailto:lc-bo...@kantarainitiative.org] De la part de J. Trent Adams
Envoyé : mercredi 17 février 2010 21:43
À : L...@kantarainitiative.org
Objet : [KI-LC] Kantara Workshop at RSA
All -
As most of you know, I've been tapped to provide the opening presentation about Kantara at the RSA Workshop in a couple weeks.
If you're interested in helping me shape what I say about your WG, please send me a 2-3 slide presentation (in .ppt format). I'll take your slides and incorporate them into the overall presentation, showcasing what you're group is doing.
... otherwise, I'm just going to make things up about your work (and we all know how that'll end up).
Cheers,
Trent
--
J. Trent Adams
=jtrentadams
Outreach Specialist, Trust & Identity
Internet Society
http://www.isoc.org
e) ad...@isoc.org
o) 703-439-2149
_______________________________________________
LC mailing list
L...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/lc
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Robert...@tbs-sct.gc.ca
The emphasis in the slide deck shows the problem only from a single RP’s point of view. There is also the IdP that has to manage substantial configuration and protocol requirements for even more numerous RP’s. I would expect the RP to IdP ratio to be around 10 to 1. The IdP may also have to participate in more than one Trust Framework and so the picture gets even more complex.
As such, I would want to at least show the advantages of configuration simplification and protocol conversion possibilities through an IdP Selector modeled with an Proxying IdP in the picture. This would certainly help clarify the ambiguities surrounding what is in the Selector and what is not.
Regards,
Bob Sunday
Security & Identity Management | Sécurité et gestion de l'identité
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Office: 613-941-4764
Email: robert...@tbs-sct.gc.ca
Government of Canada | Gouvernement du Canada
From:
wg-idp-selec...@kantarainitiative.org
[mailto:wg-idp-selec...@kantarainitiative.org] On Behalf Of philippe...@orange-ftgroup.com
Sent: February 21, 2010 1:43 PM
To:
wg-idp-s...@kantarainitiative.org
Subject: [WG-IdP-Selection] TR:
[KI-LC] Kantara Workshop at RSA
Dear all,
Trent Adams proposes during a slot in RSA (March 1st) to have a short
presentation of each WG and respective work.
I've drafted a few slides, could you please react if these ones seem to you
enough (or not) representative of what we are trying to achieve ?
<<RSA IDPS v0.1.ppt>>
Scott Cantor
> The emphasis in the slide deck shows the problem only from a single RP's
> point of view. There is also the IdP that has to manage substantial
> configuration and protocol requirements for even more numerous RP's. I
would
> expect the RP to IdP ratio to be around 10 to 1. The IdP may also have to
> participate in more than one Trust Framework and so the picture gets even
> more complex.
But what does that have to do with discovery?
Diagrams showing different places where discovery can be done are fine, but
I don't think they're necessary to explain what's in scope and what isn't.
As a technical matter, discovery is a per-RP issue. Using a proxy simply
re-labels boxes so that the real RPs no longer matter and the proxy becomes
the "single" RP in the picture.
-- Scott
_______________________________________________
WG-IdP-Selection mailing list
WG-IdP-S...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-idp-selection
Robert...@tbs-sct.gc.ca
The Identity Provider Selection Work Group Charter at http://kantarainitiative.org/confluence/display/WGIDPSEL/Charter does not have the word “discovery” in it. … though I recognize that the MRD makes extensive use of this terminology. But the MRD also does not seem to fully cover our Government of Canada use case.
The issue is one of what components participate in the “selection” and then we can talk about the “how”. Our Government of Canada situation includes:
- the SP knows the Level of Assurance (AuthnContext) it requires and it knows what Federation it is in.
- the IdP knows the Levels of Assurance which it supports and the Federation(s) it participates in and the IdP advertises them, e.g. in Metadata
- only the Principal knows which IdP’s can authenticate him/her and this information is considered “Private” and not shareable with an SP.
- Likewise, the Principal’s use of a particular SP is considered “Private” and is not shareable with an IdP.
So, we have a conundrum that requires the use of an agent independent of the SP and IdP to assist the principal’s selection while meeting the needs of the SP and the IdP. Also, this agent would have to intersperse itself in the protocol stream, or have a partner component to do this, in order to meet the above privacy requirements. As long as we’re doing this we see opportunities for protocol conversions and configuration simplification by using components, such as Proxying IdP’s. This also aligns with the concepts of a “Federation Operator” as used elsewhere in Kanatar.
If I look at the MRD requirements (Section 4) the ones that are relevant to our scenario would include:
- 7 Mechanism or capability for an ISA to show all (or part of) IdPs available to a Principal
- 9 Mechanism for ISAs to discover how each IDP needs to be displayed to the principals and/or to be used to facilitate the selection (display of the logos, search text, etc.)
- 10 Mechanism for Principal to specify the IdP and Network Authentication to access an SP
- 13 Mechanism for ISAs to discover the AuthN contexts/classes supported by IDPs
- 16 Mechanism for ISAs to discover the ALs supported by IdPs
- 19 Mechanism for ISAs to select IdPs based on the profile attributes or claims they can deliver for a Principal
- 20 Mechanism for the SP to delegate the selection (display, choice, etc.) of the IdP by Principal to an ISA (other entity/actor)
- 21 Mechanism for the SP to express some criteria (list of accepted IdPs, AuthN contexts/classes, ALs, profile attributes or claims to validate) to be considered for the selection of the IdP by the IdP Selector Agent
But this list doesn’t fulfil all of the requirements for our use case and I don’t think the MRD has a use case which specifically matches our situation.
So, my question is: does the WG-IdP-Selection help in this scenario? Or am I posing this problem to the wrong WG?
Regards,
Bob Sunday
Security & Identity Management | Sécurité et gestion de l'identité
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Office: 613-941-4764
Email: robert...@tbs-sct.gc.ca
Government of Canada | Gouvernement du Canada
From:
Scott Cantor [mailto:cant...@osu.edu]
Sent: February 23, 2010 2:03 PM
To: Sunday, Robert;
wg-idp-s...@kantarainitiative.org
Subject: RE: [WG-IdP-Selection]
[KI-LC] Kantara Workshop at RSA
Scott Cantor
> The Identity Provider Selection Work Group Charter at
> http://kantarainitiative.org/confluence/display/WGIDPSEL/Charter does not
> have the word "discovery" in it.
IdP Selection == Discovery. It's the same thing, just a common name for it.
> * only the Principal knows which IdP's
> can authenticate him/her and this information is considered "Private"
> and not shareable with an SP.
> * Likewise, the Principal's use of a
> particular SP is considered "Private" and is not shareable with an IdP.
This is immaterial to the topic at hand, but I'm just curious, are you going
to prevent the SP from knowing who the actual authenticating IdP was?
> So, we have a conundrum that requires the use of an agent independent of
the
> SP and IdP to assist the principal's selection while meeting the needs of
> the SP and the IdP. Also, this agent would have to intersperse itself in
the
> protocol stream, or have a partner component to do this, in order to meet
> the above privacy requirements.
Yes, probably so. That doesn't make anything I said wrong. Your proxy is the
only RP that matters for the purposes of "discovery", so the diagram that
applies is really the same.
> As long as we're doing this we see
> opportunities for protocol conversions and configuration simplification by
> using components, such as Proxying IdP's. This also aligns with the
concepts
> of a "Federation Operator" as used elsewhere in Kanatar.
FWIW, a federation operator and a proxy are two very different things, at
least for some of us.
> But this list doesn't fulfil all of the requirements for our use case and
I
> don't think the MRD has a use case which specifically matches our
situation.
It seems to fulfill the requirements that pertain to IdP Selection. The fact
that it doesn't mention proxies is not really a failing. It doesn't mention
any of the rest of the SSO and attribute exchange requirements either. It
doesn't need to, because there are already standards for that.
> So, my question is: does the WG-IdP-Selection help in this scenario? Or am
I
> posing this problem to the wrong WG?
IMHO, you're combining orthogonal technical concerns that come together at
implementation or deployment time. It's also a question for product
conformance as to whether the various separate concerns are all required to
be implemented in a particular scenario.
Scott Cantor
> Robert...@tbs-sct.gc.ca wrote on 2010-02-23:
>> So, we have a conundrum that requires the use of an agent independent
>> of the SP and IdP to assist the principal's selection while meeting the
>> needs of the SP and the IdP. Also, this agent would have to intersperse
>> itself in the protocol stream, or have a partner component to do this,
>> in order to meet the above privacy requirements.
>
the
> only RP that matters for the purposes of "discovery", so the diagram that
> applies is really the same.
It occurs to me, BTW, that one of your concerns may be that your
interjection of a gateway is such that the characteristics of the RP (which
is now hidden behind the gateway) is a factor in the selection of the IdP,
and if the proxy were to need to defer to some other component for
discovery, it would need a way to communicate those characteristics in some
way such that the properties of the specific RP involved was accurately
represented.
Personally I think that argues for incorporating discovery directly into the
proxy, but perhaps the "missing" MRD requirement you're looking for is the
ability to characterize the RP more dynamically than a typical approach
today would accommodate.
In other words, without a proxy, the selection process knows the RP and can
simply discover what it needs to know about it, but with a proxy, the RP is
masked off and the proxy has to represent all of them at once, which makes
the usual approaches work badly.
So the question becomes whether the scope should include protocol machinery
to accomplish that separation, and if not, the two have to be implemented as
a unit.
Does any of that resonate?
Robert...@tbs-sct.gc.ca
That’s resonating … the proxy isn’t just another RP ... I’ll think about this more later.
BTW The reason for our “privacy” requirements stems from our more restrictive legislation and oversight by the Government’s Privacy commissioner. In a nutshell, we don’t allow an IdP that may be a bank to know that the user is transacting with the Welfare Agency. And we don’t want the Tax Agency to know which banks the user is dealing with. Unless, of course, there is a due legal process taking place to investigate.
Regards,
Bob Sunday
Security & Identity Management | Sécurité et gestion de l'identité
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Office: 613-941-4764
Email: robert...@tbs-sct.gc.ca
Government of Canada | Gouvernement du Canada
From:
Scott Cantor [mailto:cant...@osu.edu]
Sent: February 23, 2010 4:24 PM
To: Sunday, Robert;
wg-idp-s...@kantarainitiative.org
Subject: RE: [WG-IdP-Selection] []
[KI-LC] Kantara Workshop at RSA
Scott Cantor wrote on 2010-02-23:
Scott Cantor
> That's resonating . the proxy isn't just another RP ... I'll think about
> this more later.
Well, it is in the sense of a protocol exchange. But some RPs exhibit
dynamic behavior that others don't. Proxies happen to always do this, which
is one reason they often don't work terribly well.
Another way of characterizing the requirement, again without any reference
to something being a proxy, is simply to note that it may be a requirement
for the relevant characteristics of RPs (and possibly IdPs) to vary such
that statically representing those characteristics isn't sufficient.
Whether that's something people want to take up or not of course is not my
call.
> BTW The reason for our "privacy" requirements stems from our more
> restrictive legislation and oversight by the Government's Privacy
> commissioner. In a nutshell, we don't allow an IdP that may be a bank to
> know that the user is transacting with the Welfare Agency. And we don't
want
> the Tax Agency to know which banks the user is dealing with. Unless, of
> course, there is a due legal process taking place to investigate.
Yes, but in return the proxy (presumably not hosted at orwell.gc.ca ;-)
knows all of that.