v3 consent to attribute release : more than per entity ID ?

[Cantor, Scott]

On 9/5/14, 4:15 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>On a recent dev call, I asked if consent to release an attribute for a
>given relying party would apply to other relying parties, and the
>response was pretty much no, which is understandable given how I
>asked. However, I came across IDP-96 again, which is a request for
>consent to be applied to more than one entity based on some criteria,
>probably from metadata.

Hadn't seen that.

>I bring this up because of client-side storage concerns. If we
>supported IDP-96, then it seems we could store the criteria for
>matching a relying party in some way besides entity ID to reduce
>storage size. But I'm not sure how to do that.

Me either. I guess thinking about it a bit, the one that comes to mind
would be a remapping list where the mappings would be N:1 from entityID to
"consent key".

But a local mapping file for that would create a maintenance hassle, which
is why ScottK is suggesting metadata. The idea, I think, would be to
support a configurable EntityAttribute in metadata to look for that tells
the consent flow to use an alt key.

>So, I guess my question is, should consent storage be keyed by entity
>ID, or something else ? My assumption is that storage should be
>per-entity ID, and applying consent to more-than-one entity would be
>done by a configured predicate of some sort.

I don't think a predicate by itself really works because of the lookup
step. You have to know how to look up the previous decision.

But a more general design would be a Function injected to map from
ProfileRequestContext to the storage key. Then it's possible to default to
the RelyingPartyId function but plug in anything else, including my
suggestion above. And we don't really have to build those initially.

In Computer Science, this is known as "making it somebody else's problem".

-- Scott