[WG-OTTO] OTTO Minutes 8/26/15

Mike Schwartz mike at gluu.org
Sun Aug 30 16:21:45 CDT 2015


Thanks for the great feedback. I made some comments inline, but we 
should discuss in more detail some of the items at the next meeting.

> If we are tasked with creation of an API, which I am assuming is a
> RESTFUL API, then the source data store is abstracted and the
> structure would be an implementation issue and not considered in
> scope.

Yes, like LDAP... how you store the data is up to the implementer.
I agree that we only want to define what is required for 

> From our discussions, we are trying to build an Identity Trust
> Framework with no boundaries.
> AFIK, all implemented Identity Trust Frameworks are for a provided
> community. (ie Healthcare or Finance)

This I am not sure about... I think a multi-party federation protocol 
should be neutral on trust models. I'd like to see OTTO support very low 
levels of assurance--for example a network for gamers where identity is 
not important, or in fact anonymity might be preferable (i.e. if kids 
are on the network). But I'd also like OTTO to support high level of 
assurance trust frameworks, for example government or supplier-vendor.

> The data structure of the returned data from the API should be in
> scope.

Yes, agreed at a high level. Ideally, we'd have implementations already, 
and the standard would provide alignment and an opportunity to curate 
the advantages pf different data structures. As OTTO is a 
"build-it-and-they-will-come" standard, I think we need to think through 
some implementations to vet our design. I think this is true especially 
as we're looking at append only data base, which is new to many of us, 
although I know the ideas been out there for some time.

> As a story around an Identity Trust Framework from real life:
> A dentist often need to refer a patient to a Specialist. Hopefully the
> dentist will do this based on his history of previous outcomes of his
> activity.
> If the dentist has had no uncomfortable experiences with the
> Specialist over several instances of interaction the the "Trust" level
> increases.
> If there is even a single uncomfortable experience with the Specialist
> the "Trust" level decreases and the dentist may decide to no longer
> refer patients.
> So if we create metadata about the Specialist from this activity, we
> could say that the metadata needs to be:
> 	* - accreditation-authority-url = Dentist
> 	* - valid-from = when the dentist first started the relationship
> 	* - valid-to = when the dentist ended the relationship
> 	* - date-of-validation = when the dentist last interacted with the
> Specialist
> 	* - number-of-interactions = number of times the Dentist has used the
> Specialist
> 	* - Trust-level = perhaps an Integer from x-to-y indicating some
> Level of Assurance (This makes "Risk" calculations easier)
> If the  metadata about the Specialist has many of these parameters it
> would cover:
> accreditation-authority-url allows for the "industry Authority" like
> the American Dental Association. Also allows consumer to query the
> accreditation-authority-url to determine their "trustworthiness"
> date-of-validation was related that the fact that the "American Dental
> Association" never re-authorises dentists. So a dentist authorized in
> 1930, might not be the best choice without other
> "accreditation-authority" values
> The  "American Dental Association" does revoke them as could be
> identified within the "valid-to" parameter.
> As most people are lazy, the "date-of-validation" parameter would show
> the last interaction to show the last time the dentist interacted with
> the Specialist.
> (Perhaps the "date-of-validation" and the "number-of-interactions"
> could be programmatically set by the dentist(s) by calling the API
> whenever there is an interaction)
> As trust has several facets, I  would expect to have a listing of
> trust authorities  similar to: (I have no passions around naming or
> schemas)
> {
>    "trust-entry":{
>       "id":"uid",
>       "value":"Specialist",
>       "cot":{
>          "entry":[
>             {
> "accreditation-authority-url":"http://americandentalassociation.com/
> [9]",
>                "valid-from":"1901-04-23T18:25:43.511Z",
>                "valid-to":"2550-10-21T13:28:06.419Z",
>                "date-of-validation":"1901-04-23T18:25:43.511Z",
>                "number-of-interactions": "120",
>                "trust-level":"3"
>             },
>             {
> "accreditation-authority-url":"http://exampledentist2.com/dentist
> [10]",
>                "valid-from":"2012-04-23T18:25:43.511Z",
>                "valid-to":"2015-10-21T13:28:06.419Z",
>                "date-of-validation":"2015-10-21T13:28:06.419Z",
>                "number-of-interactions": "1",
>                "trust-level":"2"
>             },
>             {
> "accreditation-authority-url":"http://exampledentist3.com/dentist
> [11]",
>                "valid-from":"2012-04-23T18:25:43.511Z",
>                "valid-to":"2015-10-21T13:28:06.419Z",
>                "date-of-validation":"2015-10-21T13:28:06.419Z",
>                "number-of-interactions": "1",
>                "trust-level":"2"
>             }
>          ]
>       }
>    }
> }
> This type of data allows the consumer of the metadata to create their
> own level of measurement of "trust" or utilize the "trust-level"
> provided which would be "fuzzy".

This is a very interesting use case for both centralized and 
decentralized mechanisms for managing trust. It may be a handy 
real-world metaphor. I wonder if we'd want to get to this level of 
granularity. The advantage is it solves real world problems, the 
disadvantage is that it may solve less problems than if we provide a 
more generic pattern.

> Relating to:
>  - "Attribute requirements are notoriously difficult to express,
> making out of band communication necessary anyway"
> I believe the SAML "FriendlyName" can be used to allow the SP/RP to
> request Attributes with isRequired="true":
>  <md:RequestedAttribute FriendlyName="eduPersonPrincipalName"
> Name="urn:oid:"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
>  <md:RequestedAttribute Name="urn:oid:"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> isRequired="true"/>
>  <md:RequestedAttribute FriendlyName="mail"
> Name="urn:oid:0.9.2342.19200300.100.1.3"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> isRequired="true"/>
>  <md:RequestedAttribute FriendlyName="displayName"
> Name="urn:oid:2.16.840.1.113730.3.1.241"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>

I think something like "isRequired" would be helpful. I definitely agree 
with Nate's contention that getting agreement between the IDP/SP is more 
difficult than it should be many times when setting up SAML trust.

> I believe the The OAuth Specifications state the "Client/RP" should
> not count on returned scopes being the same as requested scopes due
> tot he RO not providing consent.
> I would assume it would be up to the Client/RP to determine if they
> desired to move forward without the "Required" attributes and respond
> to the requestor as appropriate.

Sure the client can always not proceed because its missing information. 
We're trying to head off that situation by making the requirements more 
clear ahead of time.

> As an example, if we know the OID of an attribute we could then use
> http://www.oid-info.com/get/ [12] to obtain the attribute
> details. (Not RESTFul but we could define such)

I like the idea of identifying attributes with a URL in the context of a 
domain. If making a GET request to the identifier returns additional 
discovery information, this could also be useful.

> In regards to "Entity discovery is the most important use case:"
> SAML has the concept of "Common Domain" where Circles of Trust could
> be "pre-configured" by the IDP and allow them to discover a "Common
> Domain" that was trusted.
> SAML also has the "Identity Provider Proxy Specification"

SAML specifications can be found here: 

> There is no universal method to identity or discover an individual.
> (Not sure there should be)
> There is in OpenID Connect "User Input Identifier Types"
> (https://openid.net/specs/openid-connect-discovery-1_0.html#IdentifierTypes
> [13]) which has the concept of the a uniqueID with associated data.
> Implying we could have a fighting chance if we were provided:
> 	* resource acct:joe at example.com
> 	* host example.com [14]
> 	* rel http://openid.net/specs/connect/1.0/issuer [15]

Yes, I wonder if this would get us into the need to query a domain about 
information about a person. I think it would be hard to address in our 
current scope, but we're certainly open to ideas.

[2] https://global.gotomeeting.com/join/162399285
[3] tel:%2B1%20%28805%29%20309-2350
[4] tel:%2B1%20%28714%29%20551-9842
[5] http://www.turbobridge.com/international.html
[6] https://www.turbobridge.com/join.html
[7] https://www.turbobridge.com/help/Index.html?context=180
[8] http://kantarainitiative.org/mailman/listinfo/wg-otto
[9] http://americandentalassociation.com/
[10] http://exampledentist2.com/dentist
[11] http://exampledentist3.com/dentist
[12] http://www.oid-info.com/get/
[14] http://example.com
[15] http://openid.net/specs/connect/1.0/issuer

Michael Schwartz
Founder / CEO
mike at gluu.org

More information about the WG-OTTO mailing list