RE: Question on FHIR references - relative and absolute URIs

Hi All:

Aren't the relative urls used to provide  the 
consistency across sites which would be needed to 
not break signatures - unless you only sign on 
content and referred-to content, rather than on 
references, in which case the nature of the reference is irrelevant.

Paul

At 08:24 PM 2016-04-27, Vassil Peytchev wrote:
>Would adding “FHIR Canonicalization” help in 
>this case? I.e., you apply canonicalization of 
>the serialized format (format-dependent, XML 
>canonical form as an example), then replace 
>relative URL with absolute URLs (one of, and so 
>far the only form of FHIR canonicalization), and 
>then sign, you will have the same digital signature every time….
>
>From: owner-its@lists.hl7.org 
>[mailto:owner-its@lists.hl7.org] On Behalf Of Lloyd McKenzie
>Sent: Wednesday, April 27, 2016 12:11 PM
>To: tlukasik@exnihilum.com
>Cc: David Booth <david@dbooth.org>; Robert 
>Hausam <rrhausam@gmail.com>; Grahame Grieve 
><grahame@healthintersections.com.au>; 
>its@lists.hl7.org; w3c semweb HCLS <public-semweb-lifesci@w3.org>
>Subject: Re: Question on FHIR references - relative and absolute URIs
>
>Hi Thomas,
>
>Same digital signature means that - after 
>cannonicalization - there are the same 
>bytes.  That's key.  Indenting the XML changes 
>the raw bytes, but doesn't change the bytes of 
>the canonicalized form.  On the other hand, 
>changing relative URLs to full URLs does change 
>the bytes of the cannonicalized form).  It also 
>changes server-portability of instances.
>
>
>Lloyd
>
>Lloyd McKenzie, P.Eng.
>Senior Consultant, Information Technology Services
>Gevity Consulting Inc.
>
>  E: <mailto:lmckenzie@gevityinc.com>lmckenzie@gevityinc.com
>M: <tel:1-587-334-1110>+1 587-334-1110
>W: <http://gevityinc.com/>gevityinc.com
>
>GEVITY
>Informatics for a healthier world
>
>CONFIDENTIALITY – This communication is 
>confidential and for the exclusive use of its 
>intended recipients. If you have received this 
>communication by error, please notify the sender 
>and delete the message without copying or disclosing it.
>
>NOTE: Unless explicitly stated otherwise, the 
>opinions and positions expressed in this e-mail 
>do not necessarily reflect those of my employer, 
>my clients nor the organizations with whom I hold governance positions
>
>On Wed, Apr 27, 2016 at 12:28 PM, 
><<mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com> wrote:
> >> "One is "having the same bytes".  That's a 
> strict interpretation.  Another is "having the 
> same digital signature". That's looser"
>
>I'd disagree with that statement, David.
>
>To have the same digital signature it would have 
>to have the same bytes, and in fact if even a 
>single bit is different then it won't produce the same digital signature.
>
>So I don't agree that those are different 
>"definitions" of "the same thing", or that the 
>digital signature interpretation is "looser".
>
>TJL
>
>
>---------------------------- Original Message ----------------------------
>Subject: Re: Question on FHIR references - relative and absolute URIs
>From: "David Booth" <<mailto:david@dbooth.org>david@dbooth.org>
>Date: Wed, April 27, 2016 9:48 am
>To: <mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com
>"Robert Hausam" <<mailto:rrhausam@gmail.com>rrhausam@gmail.com>
>Cc: "Lloyd McKenzie" <<mailto:lloyd@lmckenzie.com>lloyd@lmckenzie.com>
>"Grahame Grieve" 
><<mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au>
>"<mailto:its@lists.hl7.org>its@lists.hl7.org" 
><<mailto:its@lists.hl7.org>its@lists.hl7.org>
>"w3c semweb HCLS" 
><<mailto:public-semweb-lifesci@w3.org>public-semweb-lifesci@w3.org>
>--------------------------------------------------------------------------
>
> > On 04/27/2016 01:33 AM, 
> <mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com wrote:
> >> >> "We always had stated that we must be able to get back "the same
> >> thing"."
> >> That's true, Rob.. we've always included round-tripability in our
> >> conversations, but (and again, please correct me if I seem to be missing
> >> or misunderstanding something), "the same thing" does not always mean
> >> the same thing.
> >> It might mean "equality" or it might mean "equivalence". That's the
> >> reason that we have both an "==" and an "===" operator in many
> >> programmimg languages.
> >> So getting back to the original question that David asked and Lloyd
> >> offered some insight into, it sounds to me like the answer is that
> >> messing with the URI's might be OK if we're only required to make sure
> >> that they're "the same thing" in the sense that they're equivalent
> >> (meaning that "they point to the same thing"), but it wouldn't be OK if
> >> they have to be "the same thing" in the stricter sense of not altering
> >> the digital signature.
> >
> > Right now we essentially have two well-defined interpretations of what
> > "the same thing" might mean. One is "having the same bytes". That's a
> > strict interpretation. Another is "having the same digital signature".
> > That's looser, but it is still a clear definition that we do not need
> > to invent. If we were to invent a third interpretation that is even
> > looser then we would have to clearly define it and describe the problem
> > that it is intended to solve. Such a definition could have some utility
> > but I am doubtful that it would be enough to justify the work and the
> > confusion that would be added by having one more notion of equivalence.
> >
> > David Booth
> >
> >> TJL
> >>
> >> ---------------------------- Original Message ----------------------------
> >> Subject: Re: Question on FHIR references - relative and absolute URIs
> >>
>From: "Robert Hausam" <<mailto:rrhausam@gmail.com>rrhausam@gmail.com>
> >> Date: Tue, April 26, 2016 11:54 pm
> >> To: <mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com
> >> Cc: "David Booth" <<mailto:david@dbooth.org>david@dbooth.org>
> >> "Lloyd McKenzie" <<mailto:lloyd@lmckenzie.com>lloyd@lmckenzie.com>
> >> "Grahame Grieve" 
> <<mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au>
> >> 
> "<mailto:its@lists.hl7.org>its@lists.hl7.org" 
> <<mailto:its@lists.hl7.org>its@lists.hl7.org>
> >> "w3c semweb HCLS" 
> <<mailto:public-semweb-lifesci@w3.org>public-semweb-lifesci@w3.org>
> >> --------------------------------------------------------------------------
> >>
> >> > Right. We always had stated that we must be able to get back "the same
> >> > thing". And signature is a means to verify that.
> >> >
> >> > Rob
> >> >
> >> > On Tue, Apr 26, 2016 at 6:05 PM, 
> <<mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com> wrote:
> >> >
> >> >> >> "It has been mentioned before, as a way to clarify what qualifies as
> >> >> successful round tripping."
> >> >>
> >> >> David..
> >> >>
> >> >> I wasn't doubting that it was ever 
> mentioned. My concern was that we may
> >> >> not be keeping the additional challenge that signing introduces in mind
> >> >> when evaluating and testing the round tripping of our prototype RDF
> >> >> instances.
> >> >>
> >> >> I think that if we *were* doing that, we would have been aware of what
> >> >> Lloyd pointed out, and have been able to answer our own question RE the
> >> >> preservation of absolute and relative URIs.
> >> >>
> >> >> TJL
> >> >>
> >> >> ---------------------------- Original Message
> >> ----------------------------
> >> >>
> >> >> Subject: Re: Question on FHIR references - relative and absolute URIs
> >> >>
> >>
>From: "David Booth" <<mailto:david@dbooth.org>david@dbooth.org>
> >> >> Date: Tue, April 26, 2016 4:05 pm
> >> >> To: <mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com
> >> >> Cc: "Lloyd McKenzie" <<mailto:lloyd@lmckenzie.com>lloyd@lmckenzie.com>
> >> >> "Grahame Grieve" 
> <<mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au>
> >> >>
> >> >> 
> "<mailto:its@lists.hl7.org>its@lists.hl7.org" 
> <<mailto:its@lists.hl7.org>its@lists.hl7.org>
> >> >> "w3c semweb HCLS" 
> <<mailto:public-semweb-lifesci@w3.org>public-semweb-lifesci@w3.org>
> >> >>
> >> --------------------------------------------------------------------------
> >> >>
> >> >> > On 04/26/2016 03:44 PM, 
> <mailto:tlukasik@exnihilum.com>tlukasik@exnihilum.com wrote:
> >> >> >> >> "If we want the RDF to be an equal sibling to xml and JSON then
> >> >> >> round tripping needs to be signature safe."
> >> >> >> David..
> >> >> >> Lloyd's comment points out the need 
> for a significant and non-trivial
> >> >> >> "uptick" in the level of care that will have to be taken when
> >> generating
> >> >> >> RDF.
> >> >> >> I certainly haven't been to every single FHIR RDF meeting (so please
> >> >> >> correct me if I'm wrong), but I don't 
> recall "signature safety" being
> >> >> >> discussed much (if at all) when we've discussed aspects of round
> >> >> tripping.
> >> >> >
> >> >> > It has been mentioned before, as a way to clarify what qualifies as
> >> >> > successful round tripping. Successful round tripping means getting
> >> back
> >> >> > "the same thing" if you convert from 
> one FHIR serialization to another
> >> >> > and back again. But in deciding what we mean by "the same thing" one
> >> >> > might not expect something like whitespace differences to count as
> >> >> > consequential differences, whereas other changes definitely should be
> >> >> > considered important. The digital signature criteria provide a way to
> >> >> > arbitrate between important and unimportant differences.
> >> >> >
> >> >> > David
> >> >> >
> >> >> >> TJL
> >> >> >>
> >> >> >> ---------------------------- Original Message
> >> >> ----------------------------
> >> >> >> Subject: Re: Question on FHIR 
> references - relative and absolute URIs
> >> >> >>
> >> >>
> >>
>From: "Lloyd McKenzie" <<mailto:lloyd@lmckenzie.com>lloyd@lmckenzie.com>
> >> >> >> Date: Tue, April 26, 2016 3:00 pm
> >> >> >> To: "Grahame Grieve" 
> <<mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au>
> >> >> >> Cc: "David Booth" <<mailto:david@dbooth.org>david@dbooth.org>
> >> >> >> 
> "<mailto:its@lists.hl7.org>its@lists.hl7.org" 
> <<mailto:its@lists.hl7.org>its@lists.hl7.org>
> >> >> >> "w3c semweb HCLS" 
> <<mailto:public-semweb-lifesci@w3.org>public-semweb-lifesci@w3.org>
> >> >> >>
> >> >>
> >> --------------------------------------------------------------------------
> >> >> >>
> >> >> >> > If we want the RDF to be an equal sibling to xml and JSON then
> >> round
> >> >> >> > tripping needs to be signature safe. At the moment, that means
> >> >> retaining
> >> >> >> > absolute vs. relative references.
> >> >> >> >
> >> >> >> > On Tuesday, April 26, 2016, Grahame Grieve <
> >> >> >> > 
> <mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au> 
> wrote:
> >> >> >> >
> >> >> >> >> well, this is tricky. technically, 
> it's not strictly required, but
> >> >> >> it's a
> >> >> >> >> lossy transform (lossy in both ways, in fact). One of the
> >> >> attractions of
> >> >> >> >> fhir;reference for me is that you can have an absolute
> >> reference for
> >> >> RDF
> >> >> >> >> and preserve the original fhir url
> >> >> >> >>
> >> >> >> >> Grahame
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Wed, Apr 27, 2016 at 3:01 AM, 
> David Booth <<mailto:david@dbooth.org>david@dbooth.org
> >> >> >> >> 
> <javascript:_e(%7B%7D,'cvml','<mailto:david@dbooth.org>david@dbooth.org');>> 
> wrote:
> >> >> >> >>
> >> >> >> >>> Grahame and/or Lloyd,
> >> >> >> >>>
> >> >> >> >>> In today's FHIR RDF teleconference, a question came up about
> >> >> >> relative and
> >> >> >> >>> absolute URIs in FHIR references.
> >> >> >> >>>
> >> >> >> >>> Must absolute and relative references be round tripped as is?
> >> I.e.,
> >> >> do
> >> >> >> >>> we need to maintain the 
> distinction between relative and absolute
> >> >> >> >>> references when round tripping, or can relative URIs be
> >> turned into
> >> >> >> >>> absolute URIs and vice versa?
> >> >> >> >>>
> >> >> >> >>> I did not see any mention of normalizing references in the
> >> >> >> discussion of
> >> >> >> >>> Canonical JSON:
> >> >> >> >>> 
> <https://hl7-fhir.github.io/json.html>https://hl7-fhir.github.io/json.html
> >> >> >> >>>
> >> >> >> >>> Thanks,
> >> >> >> >>> David Booth
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> -----
> >> >> >> >> 
> <http://www.healthintersections.com.au>http://www.healthintersections.com.au /
> >> >> >> 
> <mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au
> >> >> >> >>
> >> 
> <javascript:_e(%7B%7D,'cvml','<mailto:grahame@healthintersections.com.au>grahame@healthintersections.com.au');>
> >> >> /
> >> >> >> >> <tel:%2B61%20411%20867%20065>+61 411 867 065
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> 
> ***********************************************************************************
> >> >> >> >> Manage your subscriptions 
> <<http://www.HL7.org/listservice>http://www.HL7.org/listservice> | View
> >> >> the
> >> >> >> >> archives 
> <<http://lists.HL7.org/read/?forum=its>http://lists.HL7.org/read/?forum=its> 
> | Unsubscribe
> >> >> >> >>
> >> >> >> <
> >> >>
> >> 
> <http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its>http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its
> >> >> >
> >> >> >> >> | Terms of use
> >> >> >> >> 
> <<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> >
> >> >> >> > *Lloyd McKenzie*, P.Eng.
> >> >> >> > Senior Consultant, Information Technology Services
> >> >> >> > Gevity Consulting Inc.
> >> >> >> >
> >> >> >> > E: <mailto:lmckenzie@gevityinc.com>lmckenzie@gevityinc.com
> >> >> >> > M: <tel:%2B1%20587-334-1110>+1 
> 587-334-1110 <<tel:1-587-334-1110>1-587-334-1110>
> >> >> >> > W: <http://gevityinc.com>gevityinc.com
> >> >> >> >
> >> >> >> >
> >> >> >> > *GEVITY**Informatics for a healthier world *
> >> >> >> >
> >> >> >> > CONFIDENTIALITY – This communication is confidential and for the
> >> >> >> exclusive
> >> >> >> > use of its intended recipients. If you have received this
> >> >> >> communication by
> >> >> >> > error, please notify the sender and delete the message without
> >> >> copying or
> >> >> >> > disclosing it*.*
> >> >> >> >
> >> >> >> > NOTE: Unless explicitly stated otherwise, the opinions and
> >> positions
> >> >> >> > expressed in this e-mail do not necessarily reflect those of my
> >> >> employer,
> >> >> >> > my clients nor the organizations with whom I hold governance
> >> positions
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >>
> >> 
> ***********************************************************************************
> >> >> >> > Manage subscriptions - 
> <http://www.HL7.org/listservice>http://www.HL7.org/listservice
> >> >> >> > View archives - 
> <http://lists.HL7.org/read/?forum=its>http://lists.HL7.org/read/?forum=its
> >> >> >> > Unsubscribe -
> >> >> >>
> >> >>
> >> 
> <http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its>http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
> >> >> >> > Terms of use -
> >> >> >> 
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> 
> ***********************************************************************************
> >> >> > Manage subscriptions - 
> <http://www.HL7.org/listservice>http://www.HL7.org/listservice
> >> >> > View archives - 
> <http://lists.HL7.org/read/?forum=its>http://lists.HL7.org/read/?forum=its
> >> >> > Unsubscribe -
> >> >>
> >> 
> <http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its>http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
> >> >> > Terms of use -
> >> >> 
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> 
> ***********************************************************************************
> >> >> Manage your subscriptions 
> <<http://www.HL7.org/listservice>http://www.HL7.org/listservice> | View the
> >> >> archives 
> <<http://lists.HL7.org/read/?forum=its>http://lists.HL7.org/read/?forum=its> 
> | Unsubscribe
> >> >>
> >> 
> <<http://www.HL7.org/tools/unsubscribe.cfm?email=rrhausam@gmail.com&list=its>http://www.HL7.org/tools/unsubscribe.cfm?email=rrhausam@gmail.com&list=its>
> >> >> | Terms of use
> >> >> 
> <<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Robert Hausam, MD
> >> > <tel:%2B1%20%28801%29%20949-1556>+1 (801) 949-1556
> >> > <mailto:rrhausam@gmail.com>rrhausam@gmail.com
> >> >
> >> >
> >> 
> ***********************************************************************************
> >> > Manage subscriptions - 
> <http://www.HL7.org/listservice>http://www.HL7.org/listservice
> >> > View archives - 
> <http://lists.HL7.org/read/?forum=its>http://lists.HL7.org/read/?forum=its
> >> > Unsubscribe -
> >> 
> <http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its>http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
> >> > Terms of use -
> >> 
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
> >>
> >
>
>
>
>***********************************************************************************
><http://www.HL7.org/listservice>Manage your 
>subscriptions | 
><http://lists.HL7.org/read/?forum=its>View the 
>archives | 
><http://www.HL7.org/tools/unsubscribe.cfm?email=vassil@epic.com&list=its>Unsubscribe 
>| <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>Terms of use
>
>***********************************************************************************
><http://www.HL7.org/listservice>Manage your 
>subscriptions | 
><http://lists.HL7.org/read/?forum=its>View the 
>archives | 
><http://www.HL7.org/tools/unsubscribe.cfm?email=pknapp@pknapp.com&list=its>Unsubscribe 
>| <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>Terms of use

Paul Knapp
President
Knapp Consulting Inc.
www.pknapp.com

Tel: +1 604 987-3313
Fax: +1 604 987-3305
Cel: +1 604 250-1915
KSA: +966 54 747 4265
Skype: paulknapp

HL7 International ( www.HL7.org )
    Co-Chair: Implementable Technology 
Specifications WG; Financial Management WG; 
Foundation and Technology SD, Standards Governance Board.
    Member: FHIR Management Group; Technical 
Steering Committee; US Realm Steering Committee; Architecture Review Board
EACOE Certified Enterprise 
Architect  <http://www.eacoe.org/>www.EACOE.<http://www.eacoe.org/>org

The information in this communication, including 
any attached documentation, is intended only for 
the person or entity to which it is addressed, 
and may contain confidential, personal, and/or 
privileged information. Any unauthorized 
disclosure, copying, or taking action on the 
contents is strictly prohibited. If you have 
received this message in error, please contact us 
immediately so we may correct our records. Thank you.