[Openid-specs-risc] canonicalization and RISC profile

[Marius Scurtescu]

During our last F2F meeting at Amazon a couple of weeks ago
canonicalization of phone numbers and email addresses came up.

This came up in the context of specifying subjects. RISC is proposed to
allow emails and phone numbers to identify subjects in both SETs and also
in subject add/remove API calls.

The first question is if the RISC profile should mandate or recommend
canonicalization at all. While the obvious answer is yes, here are some
reasons why this may not be necessary or could even lead to interop issues:
- both transmitters and receivers must do their own canonicalization to
look up accounts based on user entered valiues
- canonicalization already done by transmitters and receivers most likely
will not match exactly canonicalization required by RISC profile

Considering the above, it is not clear what value is canonicalization
adding.

If the receiver for example is not canonicalizing at all, then forcing
canonicalization in RISC APIs will lead interop issues (when the SET is
sent with the canonical email then the receiver may not be able to look it
up).

The second question is how to do canonicalization, this is information
provided by Phil Hunt on how to canonicalize:

Here are the canonicalization formats for telephone and email that the IETF
> has accepted before.
> Note: this is to help specify the format of values when asking to add or
> remove a subject from a stream.
> EMAIL  A String Value that is the Email addresses for a subject.  The
> value SHOULD be specified according to[RFC5321].
> PHIONE_NUMBER  Phone numbers for the user.  The value SHOULD be specified
> according to the format defined in [RFC3966], e.g., 'tel:+1-201-555-0123'.


and regarding SCIM:

EMails
>       Email addresses for the User.  The value SHOULD be specified
>       according to [RFC5321].  Service providers SHOULD canonicalize the
>       value according to [RFC5321], e.g., "bjensen at example.com" instead
>       of "bjensen at EXAMPLE.COM".  The "display" sub-attribute MAY be used
>       to return the canonicalized representation of the email value.
>       The "type" sub-attribute is used to provide a classification
>       meaningful to the (human) user.  The user interface should
>       encourage the use of basic values of "work", "home", and "other"
>       and MAY allow additional type values to be used at the discretion
>       of SCIM clients.
> What is going on in SCIM is that service providers may wish to track
> multiple values (not just a single one).  Hence the extended text talking
> about home vs. work. etc.



A safe way to require canonicalization could be to specify that receivers
SHOULD do it (like SCIM above) and that transmitters should use the exact
value that was sent by the receiver in the subject add API when
constructing a SET..

Again, to me it is not clear what is canonicalization buying in this case.

Thoughts?

Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20171013/87b23317/attachment.html>