[Openid-specs-ab] Messages Review 2

Nat Sakimura sakimura at gmail.com
Wed Jun 5 23:43:58 UTC 2013


Thanks.

I can do edits as well.


2013/6/6 Mike Jones <Michael.Jones at microsoft.com>

>  FYI, I’ve checked in Nat’s suggested changes to Messages through Section
> 2.2.4.  Please review.  I plan to do the rest later today, but plan to
> spend at least part of my day today actually on vacation. :-)****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Wednesday, June 05, 2013 5:40 AM
>
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Messages Review 2****
>
> ** **
>
> By inconsistencies, I mean the text inconsistencies, especially between
> the main text and definitions, not only around Claims. ****
>
> ** **
>
> For example, we used to have Authentication defined as "Act of verifying
> End-User's possession of previously provisioned credentials", then saying
> something like Client Authentication clearly does not work. ****
>
> ** **
>
> In general, going over the definition at the very end of the
> standardization process is a fairly standard practice. If the text
> developed and the definition does not go well, we have to fix one of the
> other. You cannot hand-wave that. ****
>
> ** **
>
> The reason I want to define identity and identifier is that many people
> use identity as a synonym to identifier, which is not true. ****
>
> ** **
>
> In doing so, I wanted to make it sure that expansion works. (This is a
> requirement in ISO drafting; a very good practice to test the consistency.)
> ****
>
> ** **
>
> Though the original definition of identity (by ISO/IEC and ITU-T) was "set
> of attributes related to an entity", because "attributes" was replaced by
> "claims", it is now defined as follows: ****
>
> ** **
>
>  Identity: Set of Claims related to an entity. ****
>
>  ** **
>
> Then claimed identity will become "Claimed set of claims related to an
> entity". ****
>
> A bit awkward, but logically it can be OK. It could be improved, I
> thought, but I can withdraw this comment. ****
>
> ** **
>
> More fundamental problem, however, occurs when the "Claims" is expanded
>  within "identity". ****
>
> Since Claim is defined as: ****
>
> ** **
>
>  Claim: Piece of information asserted about an Entity****
>
>  ** **
>
> Then it becomes: ****
>
> ** **
>
>  Identity: Set of pieces of information asserted about an entity related
> to an entity****
>
>  ** **
>
> It does not seem to work for me. Beside repetitious "entity", those pieces
> of information does not need to be asserted. Even if none of the pieces of
> information related to the entity is asserted, the identity still exists. I
> would rather have Identity defined as: ****
>
> ** **
>
>  Identity: Set of piece of information related to an entity****
>
>  ** **
>
> to start with to avoid this problem. ****
>
> ** **
>
> As to identifier is concerned, perhaps we can get away with just defining
> identity to mitigate the confusion between identity and identifier, but
> current proposed definition of identifier seems good and certainly
> clarifies things. ****
>
> ** **
>
> Re: Offline access. ****
>
> ** **
>
> Implementers MUST read security considerations and privacy consideration
> carefully. Both have normative text in it. Security consideration section
> is not only for security geeks, nor privacy considerations is not only for
> privacy people. ****
>
> ** **
>
> Having said that, as long as the conditionals lives and some notes are put
> in the privacy consideration, I am fine with having it at the original
> location, though I really do not understand why these has to be MUST for
> some of them, especially the MUST ignore in case of response type did not
> include 'code'. I do not see the difference in the risk exposure for the
> response_type=code token" and response_type=token when the access token
> received in the front channel was used for offline access in the later
> case. ****
>
> ** **
>
> Here is my try for the additional text in privacy consideration: ****
>
> ** **
>
> <privacy considerations>****
>
> Offline access would allow user-not-in-presence and persistent query to
> the claims, posing greater privacy risk than the claims transfer when user
> is present. Therefore, it is prudent to obtain explicit consent about the
> offline access. This specification mandates the existence of the prompt
> parameter unless it is a priori known that the request complies to the
> conditions for processing in each jurisdiction. ****
>
> ** **
>
> When access token is returned in the front channel, there is a greater
> risk of it being exposed to an attacker, who would use it to access the
> userinfo later. If the access token has no capability of offline access and
> the server can differentiate whether the client request has been done
> offline or online, the risk will be substantially smaller. Therefore, this
> specification mandates to ignore the offline access request when the access
> token is transmitted in the front channel. Note that differentiating
> between online and offline access from the server can be difficult
> especially for native clients. Server may well have to rely on some
> heuristics. Also, the risk exposure for the access token delivered in the
> front channel for response type of 'code token' and that of 'token' is the
> same. Thus, the implementations should be prepared to detect from which
> channel the access token was issued and deny offline access if the token
> was issued in the front channel. ****
>
> ** **
>
> (I do not understand why we need to differentiate web and native client in
> this respect so please supply text.)****
>
> ** **
>
> Note that although these provisions requires explicit consent dialogue
> through "prompt", the mere fact that the user pressed "accept" button etc.
> might not constitute a valid consent. Developers should be aware that for
> the act of consent is to be valid, typically, the impact of the term has to
> be understood by the End-User, the consent is given at free will and not
> forced (i.e., other options has to be available), and the term is fair and
> equitable. In general, it is advisable for the service to follow the
> required privacy principles in each jurisdictions and rely on other
> conditions of processing than explicit consent, as online self-service
> "explicit consent" often does not form a valid consent in many
> jurisdictions. ****
>
> </privacy considerations>****
>
> Nat****
>
> ** **
>
>  ** **
>
>  ** **
>
> 2013/6/5 Mike Jones <Michael.Jones at microsoft.com>****
>
> What inconsistency are you trying to address?  I really don’t know.****
>
>  ****
>
> There’s no conflict in using the term Claimed Identity if “Claims” is in
> the definition of Identity because linguistically, “Claimed” is a
> completely different word, and used in a different way from “Claims”, if
> that’s the supposed inconsistency that you were trying to address.
> “Claimed” as an adjective has to do with an ownership stake.  “Claim” as a
> noun has to do with an assertion of fact.  There’s no inconsistency in
> using them together.****
>
>  ****
>
> As for moving the offline access text, there was working group agreement
> on the normative parts – especially that it **must** be ignored if used
> in the implicit flow.  We’re primarily writing these specs for developers –
> not privacy commissioners.  Developers will be much more likely to skip the
> privacy text than text that’s part of the offline_access definition.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Tuesday, June 04, 2013 5:13 PM****
>
>
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Messages Review 2****
>
>  ****
>
> In as much as I value the discussion, the inconsistency has to be removed
> from the spec. ****
>
>  ****
>
> I talked with John and came up with modified definition of Identity and
> Identifier. I can live with the following and the definition of Claims. **
> **
>
> Now you can say Claimed Identifier and Claimed Identity. If you have
> "Claim" in the definition of these, you cannot. ****
>
>  ****
>
> Identity****
>
> Set of pieces of information related to an entity****
>
>
> Identifier****
>
> String within the scope of issuer namespace that allows clients to
> correlate one or more assertions about an entity. ****
>
>
> For the MUST in the offline access case, my proposed text still keeps all
> the MUSTs. I have just qualified them instead of being unconditional, which
> is a right thing to do, then moved to Privacy Consideration section as a
> normative text, as this really is a privacy issue and not interoperability
> issue, and is important enough to bring it up in the light of privacy so
> that privacy compliance officers will notice.  ****
>
>  ****
>
> 2013/6/5 Mike Jones <Michael.Jones at microsoft.com>****
>
> Being asserted is what makes a claim a claim.  If they were indisputable
> truth, they wouldn’t be claims.  We have to leave that in.****
>
>  ****
>
> I’m actually not happy with suggestions that we significantly revise core
> definitions that have been extensively reviewed and agreed to by the
> working group before they were added to the specs.  I know that the “claim”
> definition was one that was extensively discussed.  Changing it is the
> wrong thing to be doing at this point.  We should be trying to finish – not
> changing everything around when the current definitions are already working.
> ****
>
>  ****
>
> If you believe that we need to use “attribute”, the onus is on you to
> provide specific proposed alternative language.  But I can’t agree to
> gutting the meaning of Claim, since it’s so central to what OpenID Connect
> is about.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Tuesday, June 04, 2013 4:02 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Messages Review 2****
>
>  ****
>
> Thanks Mike. ****
>
>  ****
>
> Just quickly getting back on "Claims". ****
>
>  ****
>
> I have removed the notion of being "asserted" from the definition of
> "Claim" since we are using "Claim" in the sense of "Attribute", which does
> not have the notion of being "asserted". Attributes are there whether or
> not it is asserted by somebody or not. ****
>
>  ****
>
> If you really want the notion of "asserted" in the definition of "Claim",
> we have to use "Attribute" instead in several instances. I am happier that
> way. Do you really want to go there? ****
>
>  ****
>
> Simpler way is just to drop the notion of being asserted from the
> definition of Claim and put the notion into Claims Provider definition.
> That's what I did, in the interest of time. ****
>
>  ****
>
> 2013/6/5 Mike Jones <Michael.Jones at microsoft.com>****
>
> My comments added to the attached version.****
>
>  ****
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Nat Sakimura
> *Sent:* Tuesday, June 04, 2013 4:12 AM
> *To:* openid-specs-ab at lists.openid.net
> *Subject:* [Openid-specs-ab] Messages Review 2****
>
>  ****
>
> Now I have completed the review of Messages apart from section 2.9 and
> Self-issued related things. ****
>
>  ****
>
> Many errors and omissions. On March 1, somehow, HTTP binding was
> introduced to UserInfo endpoint. Such a binding belongs to Standard, and
> not here. Since there was no commit message, the mail/minutes, and tickets
> to the effect, it took me quite a while to locate when and on what commit
> it had happened. ****
>
>  ****
>
> Some of the MUST requirements around explicit consent are too strong and
> does not account for governmental, enterprise, and consumer protection use
> cases. Such strong requirements can be written as a sector specific
> profile, but not as a base spec. ****
>
>  ****
>
>  ****
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130606/135615d0/attachment-0001.html>


More information about the Openid-specs-ab mailing list