v3 consent to attribute release : attribute hash function ?

[Tom Zeller]

On Mon, Sep 8, 2014 at 12:37 PM, Tom Zeller <tzeller at dragonacea.biz> wrote:
> On Mon, Sep 8, 2014 at 11:51 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> On 9/8/14, 12:09 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>
>>>When calculating the hash of attribute values used to determine if any
>>>values have changed since consent was last granted, should v3 use the
>>>DataSealer ? Maybe that's overkill for client-side storage since the
>>>DataSealer will be used again on the cookie.
>>
>> No, that class is for when you have to encrypt data, it doesn't hash it.
>
> Let me try to ask a better question. Given client-side storage for
> attribute consent which includes the DataSealer, how should an
> IdPAttribute be represented for values comparison ? The current way is
> hex encoding the SHA-256 hash of String values concatenated with a
> semicolon. I thought Base64 would be better than hex to reduce size.
>
> The current v3 code for consent does the same thing as v2, hex of the
> SHA-256 hash, but as written it does not work right now because
> IdPAttributeValues are not Serializable. So, wondering what to do, in
> light of the DataSealer.

Oh, and, is there a case where we just want to store the
IdPAttributeValues in plaintext ? If the DataSealer is going to
encrypt the cookie anyway, do we need the hash of values ? The hash
seems bigger than the values, is my guess.