Then this will never work for me and my businesses. I refuse to put
everything in one basket and would imagine others would feel this way as
well. I only trust a few "providers" 100%, but because some providers
will provide more services based on what I provide them I will give them
access to a small portion of info.
This is where I see many of flaws of these projects. It appears from
the information given that the idea of virtual identities is limiting
what I can do as a consumer of virtual identy information and this will
severely limit the execution.
The personal directory concept has this. Everyone can implement what
they want and I can "subscribe" to the value added pieces that I wish
since everyone will have the choice to have a different schema. The base
schema will be the same across the board as it is required to
authenticate. But, that's the only control exerted. This allows me to
vary my trust and not put all my eggs in the same basket(s). Then I can
build services on top of this consuming the different attributes I need
with a specific provider.
See...the user AND the provider/web service needs the ability to
consume/provide value-add. The ability to trust/or limit the trust is an
absolute must for any part of the schema and the schema needs to be
fully and dynamically extensible to allow for the value-add.
I may be missing the point, but I only trust a handful of
people/business and that trust is 100% for a very select few. Trust is
earned...not given.
JP
Mike Warren <address@hidden> 11/29 6:58 PM >>>
"John Pugh" <address@hidden> writes:
One issue I have with this model... I "trust" these providers only
to a certain extent. I will not allow Provider A to have x data
where I would allow Provider B to have it.
I think the point of Providers is that they're supposed to be
trusted. If you don't trust them, why are they your trusted identity
provider? (Note: ``Providers'' are different from ``Web services'',
IIUC).