[WG-OTTO] OTTO WG Minutes 10/21

Rainer Hoerbe rainer at hoerbe.at
Thu Oct 22 07:52:33 CDT 2015


I need to add: This is based on the assumption that you do not put personal contacts into the metadata, but always organization units etc. Anyway, contact data is not a core concern of metadata and could be addressed somewhere else, like in a phone directory.

- Raienr
> Am 22.10.2015 um 14:50 schrieb Rainer Hoerbe <rainer at hoerbe.at>:
> 
> No, from a legal point there is no conflict with privacy laws in those countries that limit PII to natural persons (i.e. almost all). There might be a confidentiality issue if let’s say a supply chain would like to hide business relationships or does not want to have public endpoints, but that is a policy decision of those companies.
> 
> From a technical point I have not heard any argument against removing clear text data from the ledger and put the data behind access control fences.
> 
> - Rainer
> 
>> Am 22.10.2015 um 14:33 schrieb Jim Willeke <jim at willeke.com <mailto:jim at willeke.com>>:
>> 
>> I would be very concerned about privacy with information being public.
>> There are various controversies around this type of data being public.
>> As within ICANN's policies and processes around whois display when there is a conflict with local law. (Like EU).
>> 
>> 
>> --
>> -jim
>> Jim Willeke
>> 
>> On Thu, Oct 22, 2015 at 4:12 AM, Rainer Hoerbe <rainer at hoerbe.at <mailto:rainer at hoerbe.at>> wrote:
>> The principle I wanted to make regarding the data structure is to make assertions atomar (in the sense that out ancestors though atoms are indivisible) and the set of assertions rich enough to generate complete MD. Reference identifiers (RI, aka NameIDs) are another example: An IDP would claim to provide an RI with following qualities:
>> - RI must be non-reassignable
>> - RI must be unlinkable across privacy domains
>> - RI must be persistent across user sessions
>> - RI must be opaque
>> 
>> The IDPSSODescriptor generated from that would then contain an <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat> element.
>> 
>> And yes, there would be many combinations that exceed the expressiveness of SAML MD.
>> 
>> - Rainer
>> 
>> > Am 22.10.2015 um 12:58 schrieb Rainer Hoerbe <rainer at hoerbe.at <mailto:rainer at hoerbe.at>>:
>> >
>> >
>> >> Am 22.10.2015 um 12:00 schrieb Janusz Ulanowski <janusz.ulanowski at heanet.ie <mailto:janusz.ulanowski at heanet.ie>>:
>> >>
>> >>>
>> >>>>
>> >>>> I'm also curious also  how would it look like  if client (for instance RP) has hardcoded (trusted source/federation url etc) and joins other federation (it was one of reasons to add memberOf, homeFederation and seperate entity metadata from federation one)
>> >>>
>> >>> Hmm, if it is really hard-coding there will be a need for some kind of gateway I guess.
>> >>>
>> >> I still think it's worth to consider such scenario - it would be like following graphs.
>> >> In Edugate we introduced circle of trust metadata. SP/IDP admin had to only set individual URL as source of metadata (SAML profile) and that's it. Later he can manage membership of any federation (including Edugain, campus federations, biliteral etc) on our ResourceRegistry without changing anything on his software configuration. such approach is very appreciated by our members.
>> >
>> > I see. I would not see any limitation here. Assuming that SAML Md would be generated on the fly, the single MD feed would be represented by a certain policy for the MD generator. The membership in other federation might be a multilateral decision, requiring assertions from both the respective FO and an opt-in from the entity operator. Anyway I think that it is important to separate the UI from the assertion. So the UI could stay the same, the IDP operator would opt-in into a bilateral federation (first assertion), and the FO of the other federation would confirm (second assertion). The policy that steers the generation of metadata out of the ledger would have to take this into account.
>> 
>> _______________________________________________
>> WG-OTTO mailing list
>> WG-OTTO at kantarainitiative.org <mailto:WG-OTTO at kantarainitiative.org>
>> http://kantarainitiative.org/mailman/listinfo/wg-otto <http://kantarainitiative.org/mailman/listinfo/wg-otto>
>> 
>> _______________________________________________
>> WG-OTTO mailing list
>> WG-OTTO at kantarainitiative.org <mailto:WG-OTTO at kantarainitiative.org>
>> http://kantarainitiative.org/mailman/listinfo/wg-otto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-otto/attachments/20151022/3e6c97bc/attachment.html>


More information about the WG-OTTO mailing list