[Openid-specs-ab] Messages Review 2

Nat Sakimura sakimura at gmail.com
Wed Jun 5 12:40:26 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130605/35a48d1a/attachment-0001.html>


More information about the Openid-specs-ab mailing list