Docusign SSO

[Peter Schober]

* John Dennis <jdennis at redhat.com> [2016-11-29 16:45]:
> In addition I don't see much point in adding trusted 3rd parties to
> sign and host metadata given the metadata retrieved from the entity
> can be signed and independently verified.

Signed by whom? By the entity itself? How does that raise anything
here? (Cf. self-signed TLS cert. "I claim that I'm OK, just ask me"?)

Where the metadata comes from I don't care about at all.
(If there was a way for the entity to host it itself, one that scaled,
all the better. If we had DNSSEC universally deployed I'd probably be
tempted to put it in DNS. Others are currently busy inventing a
mechanism for OIDC to use .well-known HTTP locations instead, etc.)

What's important (to some communities, at least) is the review
performed and possibly assigment of "labels" done (something like
trust marks, but not in that specific legal sense) which only means
something when performed by a trused third party, e.g.:
Entity "is bound by $this policy/contract", "is based in $this
legislation", "RequestedAttributes have been reviewed and reduced to
the minimum as per $these guidelines", etc. like some of the stuff
described here:
https://wiki.refeds.org/download/attachments/1605961/MRPS-templatev0.3.pdf
or here:
https://refeds.org/category/research-and-scholarship

Even for low-level stuff: The metadata contains cryptographic keys
which I'd trust to authenticate future protocol messages (so I'd trust
it like a CA cert).  Why should I trust that those keys are authentic?
Because the entity itself said so? Is it OK to send all kinds of data
(PII) to such a service merely because the entity was able to get a
commercial TLS cert for web server use?
-peter