[WG-OTTO] OTTO WG Minutes 10/21

Jim Willeke jim at willeke.com
Thu Oct 22 07:33:52 CDT 2015


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> 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>:
> >
> >
> >> Am 22.10.2015 um 12:00 schrieb Janusz Ulanowski <
> 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
> http://kantarainitiative.org/mailman/listinfo/wg-otto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-otto/attachments/20151022/b57e973a/attachment-0001.html>


More information about the WG-OTTO mailing list