[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Noting a change in the posted drafts (CD-1a)
I posted new drafts of all the specs over the weekend (minus authn context) incorporating the changes voted in previously, and various editorial suggestions. I wanted to highlight for discussion/decision that I felt it necessary to make one adjustment to the schema changes we approved last quorate call, in response to the thread on the "directionality" of persistent identifiers and the use of the qualifier attributes. Specifically, I realized that those qualifier attributes don't make sense for the EncryptedID element, and I tentatively removed them from that element's type (which in the posted draft is now just EncryptedElementType, with no extensions). The qualifiers really apply only to the unencrypted plaintext element, and are just part of the data that make up the NameID or BaseID being encrypted. The reason they showed up in all my working drafts on the encrypted element is due to the way encryption was handled in ID-FF. That said, I wondered if in their place we might need some additional attribute to identify the *source* of the encryption, which might not be the entity issuing the message containing the blob. I'm not 100% sure either way. I know in general, you'd expect as the consumer to be able to decrypt the key and/or the element, and it's your own key that matters, but I can see wanting to use different keys or different OOB approaches based on the guy doing the encryption, and knowing who that is might be useful. OTOH, maybe there's a way to capture that within the EncryptedData element. I don't see anything in the spec that jumps out at me though. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]