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
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).
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/ mailman/listinfo/wg-uma