You're right that to add hashed claims discovery would apply to claims generally. I was making a different case in my head, so let me spin it out a bit more here...

Thought #1: As you point out, adding more detail to hints that are targeted to claim pushing can be done in an extension or minor version update.

Thought #2: Issue #264 seems to be pointing in the direction of a valuable, generally applicable mechanism of saying: "Whatever it is the client did in Act 1 of requesting an RPT (which I'm positing might include proactively pushed claims based on some pre-negotiated out-of-band set), one of the more successful design patterns for an Act 2 might be for the AS to say 'Redirect the user to me and I'll handle it'."

Thought #3: A less success design pattern might be the hinted pushed-claims pattern, precisely because of what we see in identity federation so often: pre-negotiated out-of-band claims. The existing IdP/AP might be stuck for an answer at that point, and the AS might essentially be in "recovery mode" to wring success out of failure.

Thought #4: In this case, spending more effort on enhancing the simple claim hint structure we have, vs. the simple redirect_user hint, may be premature, especially given thought #1.

Thought #5: However, I'm totally open to input from those who are finding the claim hint structure useful for AS-client negotiation / to finding out I'm wrong about any of the above.

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Jan 8, 2017 at 12:51 PM, Justin Richer <jricher@mit.edu> wrote:

I don't reach the same conclusion regarding the interrelation between those two. Deciding not to do #264 (which I believe is the right call) doesn't mean we can't do #254 which handles claims in the general case. Still it could be potentially implemented and handled as an extension or later update, I'd at least want to see one implementation before including it.

-- Justin
On 1/7/2017 10:31 PM, Eve Maler wrote:
I'm coming to think it has relevance to issue 264 as well, as in, the direction of the consensus on 264 suggests that we might not want to take action on 254 since the latter would amount to additional special-case fiddling with claim hints to the client...
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sat, Jan 7, 2017 at 4:40 AM, Justin Richer <jricher@mit.edu> wrote:
Note all that this has relevance to the recent thread on the storage and protection of cached claims at the AS (as part of PCT processing).

-- Justin

On 1/6/2017 9:21 PM, Eve Maler wrote:
We haven't discussed this one yet, but 254: Hashed claims discovery is a proposal from Justin (and Sarah, I believe) for communicating to a client enough information about the desired claim value(s) so that it can supply the right claim(s) the AS is looking for, without exposing too much of the RO's policies, and without the client pushing too many of the RqP's claims to the AS. So the idea is for it to be mutually (well-roundedly?) privacy protective in the context of a hinted pushed-claims scenario. The issue thread includes a use case.

This one needs some discussion about the why and the privacy considerations along with the how (which may be straightforward but hasn't been spelled out yet).

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma