[Concordia] Business agreement path
Mikaël Ates
mikael.ates at univ-st-etienne.fr
Tue Jan 22 13:07:42 EST 2008
Paul,
In fact I was thinking about the business agreement path establishment
maybe combined with the example 3 of the brokered/indirect Model both
described in the "Liberty Trust Model Guidelines" which is now
OASIS-ified (sstc-saml-trustmodels-2.0-draft-01).
My question is about this extract "The process of validating a business
agreement path begins by determining whether A's BAL contains an entry
for B. If so (e.g., in the Figure 4 example, if B is Yahoo.com),
Pairwise Trust applies.* If not, A must determine whether one or more of
the entries in its BAL enables it to construct a business agreement path
to B.* It appears that the process of constructing business agreement
paths has received less study in an algorithmic sense than that of
constructing authentication paths, so its procedures may often be more
ad hoc in nature. If a business agreement path can be constructed (e.g.,
in the Figure 4 example, a path to Travelocity.com via Excite.com),
Brokered Trust applies."
I was wondering if business agreement and authentication path could be
based on metadatas (as the TAL) especially when there is a multitude of
nodes in the path... And the point, if anybody has already encountered
such a real case. Because it seems to be "difficult" to establish a
business agreement between unknown entities except if it relies on a
user's choice like in user-centric architectures (e.g. OpenId) where
indirect trust links does not really make sense.
Regards,
Mikaël
Paul Madsen wrote:
> Hi Mikael, LAP explored these sorts of inter-COT issues in
>
> http://www.project*liberty*.org/.../23105/file/access-to-identity-enabled-services-in-inter-cot-scenarios-v1.0.pdf
>
>
> I think your scenario is covered in the chapter 'Inter-Federation
> (Inter-CoT) Discovery'.
>
> FYI, ID-WSF has its Identity Mapping Service (IMS), enabling
> comparable functionality to WS-Trust token exchange.
>
> paul
>
> Mikaël Ates wrote:
>> Josh, you are totally right, it would have been better if I have kept
>> the distinction between the discovery and trust path establishment
>> issues.
>> I think that the first one can be resolved in a manner listed by Eve.
>> An information (for me, a "hint") given to the SP (whatever passive
>> or active client process used) combined with the SAML2 Metadata
>> Publication and Resolution part seem to be enough.
>> The second question is now about trust path establishment i.e. I have
>> discovered the IdP but for the moment I do not trust it yet, i.e. I
>> have its signature but I do not trust his signature yet.
>> What I said only rely on indirect trust, i.e. I can establish trust
>> paths thanks to the public metadata. Thanks to the discovery process
>> I can match one of these trust paths. I have now two possibilities,
>> my requests/responses pass through every node with resignatures like
>> SAML2 IdP proxying (heavy process but allows my SP and IP to manage
>> few signatures, the discovery process has only been used to match the
>> right trust path and the IdP signature + endpoints are useless for
>> the SP) or the SP adds the IdP metadata to its whitelist of trusted
>> IdP (the discovery process has been used to match the right trust
>> path and to obtain the metadatas).
>>
>> Paul, if I still authorize indirect (transitive) trust, could the
>> issue be the same with ID-WSF? I mean, the WSC and the WSP could
>> trust a different DS and these DS could be trust linked. So the WSC
>> could obtain a token from its DS, exchange it to the WSP'DS, and
>> present this new token to the WSP (In a WS-Trust manner in fact...).
>>
>> Regards,
>> Mikaël
>>
>> Paul Madsen wrote:
>>> FYI, Liberty's Discovery Service typically does link discovery and
>>> trust.
>>>
>>> When an Identity Requestor queries a user's Discovery Service (DS)
>>> for the location of some attribute (e.g. geolocation), the DS
>>> returns both
>>>
>>> - the endpoint of the user's geolcoation service
>>> - a security token (a SAML assertion) for the identity requestor to
>>> use at the above endpoint (thereby allowing the DS to broker trust
>>> between the requestor and the endpoint)
>>>
>>> this is seen as an optimization of having the requestor perform two
>>> separate calls, one to discover, and another to get a security token
>>>
>>> I do acknowledge that this type of service discovery is different
>>> than the more fundamental 'IDP discovery' problem.
>>>
>>> regards
>>>
>>> paul
>>>
>>> Mikaël Ates wrote:
>>>> Hi Josh,
>>>>
>>>>> Discovery and trust path establishment are orthogonal. As an
>>>>> analogy, you can use TLS to estalish trust with a peer whose
>>>>> network address you have discovered using insecure DNS.
>>>>>
>>>> In fact, in the process I described, the both are linked... The
>>>> discovery of the authority is the same as the discovery of the
>>>> trust path, and so, how to establish an indirect trust link. As an
>>>> analogy, TLS gives you signatures but does not say how you can
>>>> trust a signature. In a federation, maybe you have a common PKI, a
>>>> white list of trusted signatures, and if you rely on indirect
>>>> trust, you can trust the trusted parties of your trusted parties.
>>>>
>>>>> IIRC, eduGAIN (like the Shibboleth profile) does not consider
>>>>> discovery to be in-scope.
>>>>>
>>>> I do not know technical details of eduGAIN but I found this in the
>>>> eduGAIN deliverable DJ5.2.2:
>>>> "Home Location Service, in charge of *locating the appropriate
>>>> identity repository at the home domain*"
>>>> "An eduGAIN Home Location Request is a message sent via the
>>>> federation peering point to determine the home
>>>> interfaces where an authentication or attribute request can be
>>>> satisfied, and to *establish trust among these
>>>> interfaces and the requesting element*.
>>>>
>>>> Regards,
>>>> Mikaël
>>>>
>>>>
>>>>> best regards, josh.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: community-bounces at projectconcordia.org
>>>>>> [mailto:community-bounces at projectconcordia.org] On Behalf Of
>>>>>> Mikaël Ates
>>>>>> Sent: 22 January 2008 10:03
>>>>>> To: Eve Maler
>>>>>> Cc: community at projectconcordia.org
>>>>>> Subject: Re: [Concordia] A wiki page for our IdP Discovery
>>>>>> Problem educational materials
>>>>>>
>>>>>> Hi the Concordia community,
>>>>>>
>>>>>> Eve have posted about the "where are you from" issue. I am also
>>>>>> working on this (like everyone I guess...) so I would be pleased
>>>>>> if anybody could give me his opinion about something like "Say me
>>>>>> something about you, I will say you where you are from" and also
>>>>>> if you ever hear something about this? In fact, these works
>>>>>> mainly concern trust path establishment.
>>>>>>
>>>>>> I suppose that the SP/RP and the Authority (STS, SAML IdP,
>>>>>> etc...) are not directly trust linked. So there is "n" indirect
>>>>>> trust links and n+1 nodes. The nodes at the boundaries are the
>>>>>> security information (token, assertion,
>>>>>> etc...) producer and consumer. The "middle nodes" ensure what
>>>>>> SAML2 called "IdP proxing", which means for me transitive trust.
>>>>>> I called them trusted nodes. The issue is: the user is "on" the
>>>>>> SP and want to authn (or else) on an Authority indirectly trusted
>>>>>> by the SP (Does it sound like a reallife case?).
>>>>>> I suppose that the Authority and trusted nodes metadatas are
>>>>>> "publicly"
>>>>>> avaible which means that all the trust links can be known. So it
>>>>>> also means that it is feasable for an SP or a dedicated entity
>>>>>> (maybe a "trust router") to construct a complete "trust path table".
>>>>>> The SP asks the user a "hint", something like a URI or a domain
>>>>>> name. The SP presents the user a form or a claim requirement
>>>>>> (satisfied by an infocard containing the hint). With this hint
>>>>>> the SP is able to match one of the trust paths.
>>>>>> So the SP redirects the user to the first trusted node of the
>>>>>> path, which the SP directly trusts. The SP also gives the hint
>>>>>> while the redirection. Hence, the trusted node will perform an
>>>>>> other "jump" in the
>>>>>> path: matching and redirection.
>>>>>> One of the application I see is for a sort of internationnal
>>>>>> confederation. For now, you would have choosen your country on
>>>>>> the SP for the first redirection, your organization on the
>>>>>> trusted node, and then you would have authenticated on your IdP.
>>>>>> There, we only have one trusted node, so it is feasable to
>>>>>> require the human intervention to establish the trust path. But
>>>>>> it is not if we have n trusted nodes...
>>>>>> In fact, some confederation project (eduGAIN) rely on a common
>>>>>> PKI, so there is a common "metadatas pool" of the confederation
>>>>>> which allows to search (also thanks to a hint) the IdP directly
>>>>>> in the metadatas, and dynamically establish a direct trust link
>>>>>> between the SP and the IdP.
>>>>>> Here, I treat another case, in which we don't have a common PKI
>>>>>> or whatever secondary common trust architecture which would allow
>>>>>> a dynamic direct trust establishment. In the case of a dynamic
>>>>>> direct trust establishment, the SAML ECP profile or Infocard tech
>>>>>> would be enough to solve the WAYF issue. In fact, there is common
>>>>>> trust architecture which would be the (con)federation by itself.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Mikaël Ates
>>>>>> DIOM Laboratory - ISTASE School of Engineering University of
>>>>>> Saint-Etienne - FRANCE mikael.ates at univ-st-etienne.fr
>>>>>> +33 4 77 43 50 34
>>>>>>
>>>>>> Eve Maler wrote:
>>>>>>
>>>>>>> I finally created a place to put our IdP discovery thoughts;
>>>>>>> that action has been hanging out there for a while. Please feel
>>>>>>> free to edit, correct, flesh out, etc. Scott and Jeff and
>>>>>>> George, I'd be especially grateful for your contributions since
>>>>>>> we all indicated interest in carrying this forward.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> http://projectconcordia.org/index.php/The_Identity_Provider_Discovery_
>>>>>>
>>>>>>
>>>>>>> Problem
>>>>>>>
>>>>>>> By the way, in some private conversations I've been having,
>>>>>>>
>>>>>> it seems
>>>>>>
>>>>>>> deployers would find a similar exercise for single logout to be
>>>>>>> useful. It's got some of the same characteristics: sensitive to
>>>>>>> UI concerns, decisions get based as much on business as
>>>>>>> technical considerations, confusing, no one perfect solution vs.
>>>>>>> lots of imperfect solutions that involve tradeoffs... If you're
>>>>>>>
>>>>>> interested,
>>>>>>
>>>>>>> please raise your hand (or just start writing a new page!).
>>>>>>>
>>>>>>> Eve
>>>>>>>
>>>>>>> Eve Maler +1 425 947 4522
>>>>>>> Principal Engineer eve.maler @ sun.com
>>>>>>> CTO Business Alliances group Sun Microsystems, Inc.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Community mailing list
>>>>>>> Community at projectconcordia.org
>>>>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>>>>
>>>>>>> Participating in this discussion list does not grant any
>>>>>>>
>>>>>> intellectual property rights or any commitment by the
>>>>>> participants of the content discussed to any organization.
>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Community mailing list
>>>>>> Community at projectconcordia.org
>>>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>>>
>>>>>> Participating in this discussion list does not grant any
>>>>>> intellectual property rights or any commitment by the
>>>>>> participants of the content discussed to any organization.
>>>>>>
>>>>>>
>>>>> JANET(UK) is a trading name of The JNT Association, a company limited
>>>>> by guarantee which is registered in England under No. 2881024 and
>>>>> whose Registered Office is at Lumen House, Library Avenue,
>>>>> Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
>>>>>
>>>>> _______________________________________________
>>>>> Community mailing list
>>>>> Community at projectconcordia.org
>>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>>
>>>>> Participating in this discussion list does not grant any
>>>>> intellectual property rights or any commitment by the participants
>>>>> of the content discussed to any organization.
>>>>>
>>>>
>>>> _______________________________________________
>>>> Community mailing list
>>>> Community at projectconcordia.org
>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>
>>>> Participating in this discussion list does not grant any
>>>> intellectual property rights or any commitment by the participants
>>>> of the content discussed to any organization.
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
More information about the Community
mailing list