Date: Fri, 29 Mar 2024 04:46:27 +0000 (UTC)
Message-ID: <1151344462.7447.1711687587495@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7446_515508985.1711687587493"
------=_Part_7446_515508985.1711687587493
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Date:
October 30, 2013
Time:
12 Noon Eastern, 9AM Pacific, 5PM UK
Dial-in Info:
+1-734-615-7474 (English I2, Please use if you do not pay for Long Dista=
nce),
+1-866-411-0013 (English I2, toll free US/Canada Only)
PIN: 0195401 #
Agenda:
- IdP extensions from to incor=
porate a service provider's registrationAuthority value into attribute rele=
ase policies (email from Ian).
- Discussion of Code of Conduct ser=
vice category and technical implications (email from Tom).
- REFEDs meeting next week.<=
/li>
- AOB
Attending:
Warren Anderson, Steve Olshansky, Ian Young, Scott Cantor, Tom Scavo, I.=
J. Kim, Steven Carmodie, John Kreinke
Recording:
https://edial.internet2.edu/call/0104276
Minutes:
- IdP extensions from to incor=
porate a service provider's registrationAuthority value into attribute rele=
ase policies (email from Ian).** Straightforward for Shib 2.x#* Allows keying attribute release and registration authority
- Primarily aimed at enabling dropp=
ing edugain metadata into UK Federation
- LIGO might be able to make use of=
it fairly quickly
- Discussion of Code of Conduct ser=
vice category#* Lawyers have b=
een asked to comment on whether they can sign off on meeting registration p=
age can say it complies with CoC
- Steven gives brief history of whe=
re policy comes from#** implem=
entation of EU privacy law and directive
- differs slightly from country to =
country to comply with local laws
- attempt to reduce risk of privacy=
- rules out optional attributes
- recognizes EU and countries with =
comparable privacy laws (Canada) or assurances from other countries that ar=
e sufficient (US Safe Harbor)
- Goal is to automate release of PI=
I based on information provided by relying parties
- Tom dives into technical details<=
/span>#** complicated so this is base=
d on best understanding
- Tom most recently dove into it to=
help TAC review proposal
- REFEDs is proposing R&S and C=
oC specs (and now others)#*** =
R&S spec is one pager
- CoC is multi-doc and complicated,=
needs to be simplified
- Notable operational differences b=
etween R&S and COC:#*** Co=
C requires privacy policy to be published
- CoC has reliance on RequestedAttr=
ibutes in metadata (so does R&S but in other ways)
- RequestedAttributes are supposed =
to be FYI - few IdPs in InCommon supply them unlike in other federations.=
span>
- This is partly an implementation =
issue (simpleSAMLphp vs Shibboleth) - simpleSAMLphp relies on RequestedAttr=
ibutes.
- One other difference is an xml at=
tribute of isRequired for RequestedAttributes, which is not a supported att=
ribute for inCommon (because inC uses ReqAttr as FYI)
- Tom will be asking for one page s=
ummary of CoC (like R&S) and may have suggestions for
- Scott thinks RequestedAttributes =
could be considered useful, but the issue is more that it is not used becau=
se we use back-channel
- Also thinks that it doesn't suppo=
rt our use case because the way we use attribute information is too rich&nb=
sp;
- Also no SPs are willing to take i=
t
- Tom points out RequestedAttribute=
is insufficient for R&S attribute bundle
- Steven thinks we need to start de=
fining best practices to simplify the way we use attributes#*** For instance, IdP asking user "we are rel=
easing your name to this SP, is that OK"?
- Tom points out that in R&S th=
e policy for names is not expressible #*** Scott disagrees, is possible but just not with isRequired=
- Scott thinks we ether need to get=
everyone to start over with new "best practices" or get to a small set of =
RequesteAttribute metadata.
- Tom thinks it's obvious that the =
Attribute Bundle idea from R&S is a better way to go
- Warren asks if this is just throw=
ing it back over the fence - is it just as difficult to implement Attribute=
Bundles in simpleSAMLphp as it is to do RequestedAttributes in Shibboleth?=
#*** Scott and Tom suspect thi=
s must be possible based on principal and prior experience.
- Steven thinks that attribute bund=
les will contain attributes that are not required by SP, which is a violati=
on of CoC.
- Tom points out that bundles can b=
e reduced based on relying party metadata (work done by Scott) but is large=
ly unleveraged.
- Scott thinks that this doesn't re=
ally work for required attributes - it works for signaling when you won't u=
se it, but that's not the same as only passing required activity.
- In fact, Scott thinks that the im=
plementation that are being suggested are incompatible with the directive.<=
/span>
- Scott wonders if this is even whe=
re interfederation should start? Seems ambitious to try to bring so many Id=
Ps under the tent initially. Seems like an intractable problem.
-
------=_Part_7446_515508985.1711687587493--