[Openid-specs-fastfed] Notes for IIW Session: OTTO-ifying Fast Fed / Thu 11am by Mike Schwartz
Mike Schwartz
mike at gluu.org
Sun May 7 18:28:44 UTC 2017
IIW SESSION: OTTO-ifying FastFed
The IDP's and RP's of a federation need to agree on certain things
to drive down the cost of single sign-on. This includes user
claims, but may also include OAuth scopes and authentication details
like acr and amr. (See OpenID Connect client metadata for a defintion
of these terms:
http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata
)
OTTO is a set of API's and a JSON model that can be used to automate
the operation of a multi-party federation (like InCommon...) The OTTO
WG decided to leverage JSON-LD. There is an extensive schema already
defined
at https://schema.org In particular, we re-used the JSON-LD classes for
Organization and Thing quite a bit. See:
https://schema.org/Thing
https://schema.org/Organization
The advantage of JSON-LD was that it provided some linked data
capabilities,
but looked like "normal" JSON to developers who didn't care about these
features.
On Tue, Darin McAdams presented an overview of progress in the OpenID
FastFed Workig Group: http://openid.net/wg/fastfed/ You can see a spec
straw man at: http://gluu.co/fast-fed-strawman
In that document, a configuration response from an IDP is proposed:
{
“identity_provider”: {
“name”: “Awesome IdP”
“logo_uri”: “https://example.com/images/idp_logo.png”,
“auth_protocols”: [“SAML”,”OIDC”], #In practice, only 1 protocol
typically
chosen.
“saml_metadata_uri”:
“https://tenant12345.example.com/saml-metadata.xml”,
“oidc_configuration_uri”:
“https://tenant12345.example.com/oidc-configuration”,
“token_endpoint”: “https://tenant12345.example.com/token”,
“scim_endpoint”: “https://tenant12345.example.com/scim”,
“supported_attributes”: {
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
"id",
"userName",
"name": {
"familyName",
"givenName",
},
"displayName",
"emails",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber",
"costCenter",
"manager": {
"value"
}
}
}
}
Mike Schwartz's feedback was that perhaps OTTO's JSON-LD model could
enable a more elegant expression of this information.
Current draft OTTO JSON-LD vocabulary can be found here:
- OTTO Core Vocab : http://gluu.co/otto-vocab
- OTTO OpenID Vocab : http://gluu.co/openid-vocab
OTTO Vocab defines several classes:
Registration Authority
Federation
Participant
Entity
Metadata
Schema
OpenID provides more specific classes:
OpenID Provider (subclass of Entity)
OpenID Relying Party (subclass of Entity)
User Claim (subclass of Schema)
Scope (subclass of Schema)
Metadata Statement (subclass of Metadata)
Categories (Defines values of enumeration like "OpenID Connect user
claim")
An entity, like an OpenID Provider, could reference certain schema as
supported
by either linking to it, or providing the schema JSON-LD in the
"supports"
property. Of course, an array can be used to specify multiple schema
objects.
Any schema object can specify certain common properties like:
name
description
required (boolean)
url
category (to enable searches like: return all "OpenID Connect Scopes")
sameAs
The "sameAs" property could be used to specify equivilancy. For example,
an OpenID Connect Provider may use the claim "family_name", which is
equivalent
to "sn" in SAML. Using links enables the specific schema objects to
describe
what's relevent to their counter parties (like SAML2 URI, which OpenID
Connect
client's wouldn't care about.)
Currently OTTO has only defined a profile for OpenID Connect, but SAML
is in
the works. A profile for SCIM also seems like a good idea. Another
advantage
of using OTTO is that it is inherently extensible locally, or through
the
collaboration of standards groups or ecosystems.
Using OTTO to define a Fast Fed IDP response, perhaps it could look
something
like this:
{
"entity": [{SAML IDP}, {OpenID Provider}],
"Schema": [ {OpenID UserClaim 1},
{OpenID UserClaim 2},
{SCIM UserClaim 1},
{OpenID Connect ACR},
...],
"Organization": {}
}
The above syntax is simpler and is potentially more expressive, and more
standard (by leveraging
existing schema from schema.org).
More information about the Openid-specs-fastfed
mailing list