[WG-OTTO] OTTO Minutes 8/26/15
mike at gluu.org
Fri Aug 28 15:29:38 CDT 2015
OTTO WG Minutes 8/26/15
## Voting Members Attending:
## Non-voting members
## Topics discussed
NOMINATIONS / VOTING
We will open nominations for roles the week of 9/2 - 9/8, hold voting
the week of 9/9-9/15.
Roles will be two co-chairs and specification editor.
1) Scope / Schedule
Entity discovery is the most important use case:
1) Discussion of metadata data structure
- "Attribute requirements are notoriously difficult to express, making
out of band communication
NK: No good way to signal which attributes the RP wants to receive--for
example which are required, which
are optional. The goal of the federation was to reduce out-of-band
communication, why doesn't
metadata solve this? Attributes, trusted authorities still require
manual communication. How
also to facilitate comprehensible consent messages.
KH: If we move this information to metadata, the question becomes who
maintains the metadata?
Someone still has complicated work to do. Is it asking a lot of the
And does it add complexity to the design of the metadata?
NK: Less complicated when information is static, but more interactive
endpoints have more
trust considerations. Out of band gives us a lot of flexibility.
NK: What about metadata about attributes? Is EPPN non-re-assignable?
Maybe an IDP can share this,
and it would be meaningful to an RP.
MS: SAML metadata can enable SP's to request attributes. For example,
from InCommon's metadata
Doesn't which are required for what functionality: more detail is
needed. What is the policies
at the SP for this attribute? What happens if the attr is not provided?
Judith asked if Name Identifier is considered an attribute. Nate
mentioned that he wondered
if SAML2's use of NameID has problems. How about using nameID's across
RP's? Having a unique
name for users, and a human understandable name for users present
Perhaps an implementation can use attribute in a way that make name id's
Judith does think that name or sub should have special status, because
it so important to
present a consistent user experience. The pointer to the record is a
that has considerations by the IDP (i.e. non-reassignability).
IDP's aren't providing enough information to Service Providers, for
example how to de-provision.
Nate's document doesn't mention specific federation protocols by design.
Both connect and SAML
Tradeoff of optionality versus cost of operation and interoperability.
Identity data could change
completely, because we're not relying on it to point to a person.
- "Dynamic metadata has been difficult to get done, and that’s because
we’re trying to build DNSSEC +
IPsec rather than TLS... Every entity name must be a URL that is
resolvable into a description of the
entity and how to talk with it."
DNSSEC has trouble answering in the negative: how could InCommon say the
Polish federation does not have
this provider? It is too hard to come up with an exhaustive list? Give
people the ability to post
information about themselves. You're not trying to capture all
identities--but verify a particular entity
that you're taking to.
Move to a standard way to get directly to the Provider, and learn how
to validate their metadata.
Centralized models have trouble with "chaining"--a distributed model
provides a more decentralized,
alternative trust model.
If you start at the Provider rather than the Federation--all sorts of
trust models become unlocked.
Trust models don't have to be centralized, but could be reputation
based. Could providers vouch for
each other? By being able to "chase" references, you can discover more
data to enable trust.
Keith pointed out that the federation does provide an extra layer of
trust in some circumstance.
Rely on TSL for "I'm communicating with this entity." Perhaps the trust
model provided by the
federation could supplement the domain asserted information--for
example this is the key that you
Next week's Meeting Details - same time / same place!
Screen Sharing: https://global.gotomeeting.com/join/162399285
Audio: Skype: +99051000000481
North America Toll: +1 (805) 309-2350
Alternate Toll: +1 (714) 551-9842
International Toll: http://www.turbobridge.com/international.html
Conference ID: 613-2898
Command Menu: 0 Plays menu of Keypad Commands *3 Promote to Host (if
non-host) *5 Raise your hand *6 Mute yourself
(toggle on/off) *# Private roll call of participants *\ Mute
music-on-hold (toggle on/off)
TurboPhone (beta): https://www.turbobridge.com/join.html Works with
Internet Explorer on Windows only
SIP Access (using IP phone or soft phone) sip:bridge at turbobridge.com
SIP URL details: https://www.turbobridge.com/help/Index.html?context=180
More information about the WG-OTTO