[OpenID] extending host-meta beyond IETF extensions; ws-security policy like rules

[Peter Williams]

if one buys into host-meta, using scopes to indentity for which URI (user)
identifies this host is authoritative (particularly in  world where cloud
providers on 1  domain supports app-domains on other domains) I can see more
scope rules being required.

On an app-domain basis, and then a per-user basis, each overriding the cloud
providers scope, host-meta scopre for "authoritative sreg attributes" might
be added to the app-domain's host-meta file.

The RP might want to know which attibutes the app-domain has "verified", and
speaks for (above and beyond the cloud provider merely forwarding the values
from the users profile).

Despite having outsourced to google discovery and per-user profile
management for my app domain on my domain's URI, I app domain assert that I
legallty represent the value of sreg.website to be in compliance with my
posted policy (also hanging off of my app domains host-meta).

In all likelihood, this day and age, the policy would be an RDFa document,
so its readable by hiumans amd the machie-readable elements can express
rules in an algerab not dissimialr to ws-securitypocliy (controlling which
claims are required at which RPs, and which an IDP (i.e. app-domain, not
cloud provider) is itself will to vouch for, legally.
-- 
View this message in context: http://old.nabble.com/extending-host-meta-beyond-IETF-extensions--ws-security-policy-like-rules-tp26134827p26134827.html
Sent from the OpenID - General mailing list archive at Nabble.com.