Subject: [webfinger] Redefining "properties"

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 12 Aug 2014 02:29:33 +0000

Folks,

I have been asked by multiple people for different purposes to see if it 
might be possible to redefine "properties" in the JSON Resource 
Descriptor.

Per RFC 7033, "properties" is defined as an object that has zero or more 
name/value pairs whose values are strings or null.  The suggestion is 
that the values should be any valid JSON type.  Thus, a property might 
refer to a string (as is does now) or it might refer to an object or 
array.

This change would break any parsers strictly implement definition of 
"properties".  So, there are two questions I want to present to those 
who are interested:

1) Would you be agreeable to change the current definition of 
"properties" to allow any value type?
2) If not, would be agreeable to introducing something like "properties" 
that essentially allows for the same and, if so, what should this new 
object be named?

Personally, as much as I don't like breaking backward-compatibility, I'm 
favorable to redefining properties to accomodate what people want to do. 
  I'm willing to work on an RFC 7033bis and/or a new RFC to update the 
JRD specification, if folks are agreeable to either (1) or (2).

Paul

---

From: Will Norris <[email-masked]>
Date: Mon, 11 Aug 2014 20:39:19 -0700

what are the actual use cases prompting this?  If folks are trying to store
more complicated data, why is it not just a linked resource?

Personally, as a client author, I've always hated it when APIs have
polymorphic data types like this.

On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger <
[email-masked]> wrote:

> might be possible to redefine "properties" in the JSON Resource Descriptor.
>
> name/value pairs whose values are strings or null.  The suggestion is that
> the values should be any valid JSON type.  Thus, a property might refer to
> a string (as is does now) or it might refer to an object or array.
>
> "properties".  So, there are two questions I want to present to those who
> are interested:
>
> I'm willing to work on an RFC 7033bis and/or a new RFC to update the JRD
> specification, if folks are agreeable to either (1) or (2).
>
> Paul
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "WebFinger" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email-masked].
> For more options, visit https://groups.google.com/d/optout.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 16 Aug 2014 19:05:45 +0000

Will,

Sorry for the slow response.  I've been busy.

Yes, folks do want to put more complex data into JRD as opposed to 
linking, including objects or arrays.  I can see how this can be abused, 
but then I can also see an argument for not linking to data that could 
be trivially represented inside the JRD itself.

Unfortunately, I do not have details of the specific use cases.  All I 
do know is that there people working on unrelated applications where 
they want to be able to  do things like this with WebFinger:

"properties" :
{
   "http://example.com/ns/foo" :
   {
     "a" : "Hello",
     "b" : 32
   }
}

Perhaps what might be worse is the possibility that people do this:

...
"properties" :
{
   "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}"
}
...
When working on WebFinger, there was a desire to keep it as simple as 
possible.  However, I fully appreciate why some would want to do 
something like this.  Sometimes, linking to external resources is 
"overkill" for the task at hand.  And, you're right that dealing with 
polymorphic data types can be a pain.  Then again, the JSON parser deals 
with much of this automatically and the client is likely going to only 
be looking for known members, anyway.

So, I'm not sure what to do here.  I'm OK with making a change.  It 
bothers me that we might break any client code that assumes all 
properties are strings.  But, there is always the option to add some 
other member named something other than "properties".

I take it you're not too keen on the idea, though.

Paul

------ Original Message ------
From: "Will Norris" <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Sent: 8/11/2014 11:39:19 PM
Subject: Re: [webfinger] Redefining "properties"

>what are the actual use cases prompting this?  If folks are trying to 
>store more complicated data, why is it not just a linked resource?
>
>On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger 
><[email-masked]> wrote:
>>Folks,
>>
>>I have been asked by multiple people for different purposes to see if 
>>it might be possible to redefine "properties" in the JSON Resource 
>>Descriptor.
>>
>>Per RFC 7033, "properties" is defined as an object that has zero or 
>>more name/value pairs whose values are strings or null.  The 
>>suggestion is that the values should be any valid JSON type.  Thus, a 
>>property might refer to a string (as is does now) or it might refer to 
>>an object or array.
>>
>>2) If not, would be agreeable to introducing something like 
>>"properties" that essentially allows for the same and, if so, what 
>>should this new object be named?
>>
>>Personally, as much as I don't like breaking backward-compatibility, 
>>I'm favorable to redefining properties to accomodate what people want 
>>to do.  I'm willing to work on an RFC 7033bis and/or a new RFC to 
>>update the JRD specification, if folks are agreeable to either (1) or 
>>(2).
>>
>>Paul
>>
>>
>>--
>>
>>---
>>You received this message because you are subscribed to the Google 
>>Groups "WebFinger" group.
>>To unsubscribe from this group and stop receiving emails from it, send 
>>an email to [email-masked].

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Aug 2014 19:21:25 +0000

People want to put JWK Sets into the results.
________________________________
From: Paul E. Jones<mailto:[email-masked]>
Sent: ‎8/‎16/‎2014 12:05 PM
To: Will Norris<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [webfinger] Redefining "properties"

Will,

Yes, folks do want to put more complex data into JRD as opposed to linking, including objects or arrays.  I can see how this can be abused, but then I can also see an argument for not linking to data that could be trivially represented inside the JRD itself.

Unfortunately, I do not have details of the specific use cases.  All I do know is that there people working on unrelated applications where they want to be able to  do things like this with WebFinger:

"properties" :
{

...
"properties" :
{
  "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}"
}
...
When working on WebFinger, there was a desire to keep it as simple as possible.  However, I fully appreciate why some would want to do something like this.  Sometimes, linking to external resources is "overkill" for the task at hand.  And, you're right that dealing with polymorphic data types can be a pain.  Then again, the JSON parser deals with much of this automatically and the client is likely going to only be looking for known members, anyway.

So, I'm not sure what to do here.  I'm OK with making a change.  It bothers me that we might break any client code that assumes all properties are strings.  But, there is always the option to add some other member named something other than "properties".

Paul

------ Original Message ------
From: "Will Norris" <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Cc: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Sent: 8/11/2014 11:39:19 PM
Subject: Re: [webfinger] Redefining "properties"

what are the actual use cases prompting this?  If folks are trying to store more complicated data, why is it not just a linked resource?

Personally, as a client author, I've always hated it when APIs have polymorphic data types like this.

On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

I have been asked by multiple people for different purposes to see if it might be possible to redefine "properties" in the JSON Resource Descriptor.

Per RFC 7033, "properties" is defined as an object that has zero or more name/value pairs whose values are strings or null.  The suggestion is that the values should be any valid JSON type.  Thus, a property might refer to a string (as is does now) or it might refer to an object or array.

This change would break any parsers strictly implement definition of "properties".  So, there are two questions I want to present to those who are interested:

1) Would you be agreeable to change the current definition of "properties" to allow any value type?
2) If not, would be agreeable to introducing something like "properties" that essentially allows for the same and, if so, what should this new object be named?

Personally, as much as I don't like breaking backward-compatibility, I'm favorable to redefining properties to accomodate what people want to do.  I'm willing to work on an RFC 7033bis and/or a new RFC to update the JRD specification, if folks are agreeable to either (1) or (2).

Paul

--

---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked]<mailto:[email-masked]>.
For more options, visit https://groups.google.com/d/optout.

---

From: Will Norris <[email-masked]>
Date: Sun, 17 Aug 2014 20:36:14 -0700

On Sat, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger <
[email-masked]> wrote:

> but then I can also see an argument for not linking to data that could be
> trivially represented inside the JRD itself.
>
>  Unfortunately, I do not have details of the specific use cases.
>

as a rule, I think suggestions for major changes to spec should always be
accompanied by concrete use cases that necessitate the change, ever more so
when we're talking about *breaking* changes to a *finalized* spec.  (in
this case Mike did provide an example later, so my comment is more to the
fact that his was proposed in the first place without an actual use case in
mind)

> All I do know is that there people working on unrelated applications where
> possible.  However, I fully appreciate why some would want to do something
> like this.  Sometimes, linking to external resources is "overkill" for the
> task at hand.  And, you're right that dealing with polymorphic data types
> can be a pain.  Then again, the JSON parser deals with much of this
> automatically and the client is likely going to only be looking for known
> members, anyway.
>

it depends very much on what the code is doing.  If you're just relying on
a JSON parser to parse an unknown structure, it's unlikely anything too bad
will happen.  However, if you're specifically trying to unserialize the
properties object into a string=>string map, then you would likely get a
parsing error.

> bothers me that we might break any client code that assumes all properties
> are strings.
>

"client code that assumes all properties are strings" almost sounds like
they took a shortcut or something.  This could also be spelled "client code
that implemented the spec as written"... *of course* they may have assumed
properties would be strings, that's what the spec said they would be (or
null).

> But, there is always the option to add some other member named something
> other than "properties".
>

I think that option should certainly be explored at least.  In fact, that's
something that can already be done today, no?  I don't think webfinger
precludes including other JSON values, does it?

Certainly, making breaking changes does bother me, though I still don't
think there as been THAT much adoption in the wild yet, so I don't know how
much would really be at risk of breaking.  What is the process for making
this kind of change anyway?  Publish an entirely new RFC that updates 7033?
 Publish a rewritten spec that obsoletes 7033 altogether?

As a separate issue, and I don't recall to what extent this was discuss
before, but this also makes me worry a little about the size of the data
people are looking to add to a webfinger document.  At least with links,
you can request just the links you care about with the "rel" query
parameter, but no such filtering mechanism exists for properties.  Plus I
have no idea how well supported the "rel" parameter is in webfinger servers
anyway (I know I don't support it on my personal site, but that's just me).

I know that nothing is stopping someone from throwing a megabyte worth of
data in a property string today, so this "problem" (as much as it really
is) already exists today.  But I worry that changing properties to accept
arbitrary JSON data may entice people to shove larger amounts of data in a
JRD than perhaps should be.  Gzip helps you to a degree, but I don't think
JWT sets, for example, compress much.

Ultimately, whether properties are strings or JSON objects, it's up to the
application to decide where they're going to look for what data, and
therefore what they instruct users to publish in their webfinger document.
 Perhaps what I'm suggesting is just that if new text does end up getting
written to support JSON properties, then perhaps a note to implementors
should be added to caution against adding too large of data (for some
definition of "large")?

-will

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Aug 2014 20:10:13 -0400

I will also note that embedding a JWKS directly is not necessarily a good thing unless you are dynamically generating the JRD.

In Connect registration we originally only had jwks_uri to include them by reference.  Allowing a client to push a JWK inline came later.

JWKS can easily be referenced with a link from a JRD.  There may be other resins to allow complex types but I don’t think JWKS inline is a compelling one.

John B.

On Aug 17, 2014, at 11:36 PM, Will Norris <[email-masked]> wrote:

> On Sat, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger <[email-masked]> wrote:
> Will,
>  
> as a rule, I think suggestions for major changes to spec should always be accompanied by concrete use cases that necessitate the change, ever more so when we're talking aboutbreaking changes to a finalized spec.  (in this case Mike did provide an example later, so my comment is more to the fact that his was proposed in the first place without an actual use case in mind)
>  
> All I do know is that there people working on unrelated applications where they want to be able to  do things like this with WebFinger:
>  
> "properties" :
> {
> it depends very much on what the code is doing.  If you're just relying on a JSON parser to parse an unknown structure, it's unlikely anything too bad will happen.  However, if you're specifically trying to unserialize the properties object into a string=>string map, then you would likely get a parsing error.
>  
>  
> So, I'm not sure what to do here.  I'm OK with making a change.  It bothers me that we might break any client code that assumes all properties are strings. 
> 
> "client code that assumes all properties are strings" almost sounds like they took a shortcut or something.  This could also be spelled "client code that implemented the spec as written"... of course they may have assumed properties would be strings, that's what the spec said they would be (or null).
>  
> But, there is always the option to add some other member named something other than "properties".
>  
> I think that option should certainly be explored at least.  In fact, that's something that can already be done today, no?  I don't think webfinger precludes including other JSON values, does it?
> 
> Certainly, making breaking changes does bother me, though I still don't think there as been THAT much adoption in the wild yet, so I don't know how much would really be at risk of breaking.  What is the process for making this kind of change anyway?  Publish an entirely new RFC that updates 7033?  Publish a rewritten spec that obsoletes 7033 altogether?
> 
> 
> As a separate issue, and I don't recall to what extent this was discuss before, but this also makes me worry a little about the size of the data people are looking to add to a webfinger document.  At least with links, you can request just the links you care about with the "rel" query parameter, but no such filtering mechanism exists for properties.  Plus I have no idea how well supported the "rel" parameter is in webfinger servers anyway (I know I don't support it on my personal site, but that's just me).
> 
> I know that nothing is stopping someone from throwing a megabyte worth of data in a property string today, so this "problem" (as much as it really is) already exists today.  But I worry that changing properties to accept arbitrary JSON data may entice people to shove larger amounts of data in a JRD than perhaps should be.  Gzip helps you to a degree, but I don't think JWT sets, for example, compress much.
> 
> Ultimately, whether properties are strings or JSON objects, it's up to the application to decide where they're going to look for what data, and therefore what they instruct users to publish in their webfinger document.  Perhaps what I'm suggesting is just that if new text does end up getting written to support JSON properties, then perhaps a note to implementors should be added to caution against adding too large of data (for some definition of "large")?
> 
> -will
> 
> 
>> On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger <[email-masked]> wrote:
>> Folks,
>>  
>> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].