Re: [GNAP] Feedback on polymorphism

[Fabien Imbault <[e-mail]>]

Thanks Dick, interesting ! I'll add that to my list.
Maybe we could liaise with the JSON schema team if it helps.

In the meantime, I'll focus on how to implement my json polymorphism ;-)

On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt <[e-mail]> wrote:

> I exchanged some emails with the JSON Schema team last summer. They are
> actively working on a revision to better server OpenAPI.
>
> They felt stonewalled at the IETF and now question the value of spending
> time in a standards body.
>
> Another schema option is JSON Type Definition [1], which is built on CDDL
> (RFC 8610) [2], the CBOR type language.
>
>
> [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition
> [2] https://tools.ietf.org/html/rfc8610
>
>
> ᐧ
>
> On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Hi Yaron,
>>
>> Thanks a lot for the feedback, I fixed the issue related to the
>> standardisation status (I guess there's some historic background that I
>> don't know ;-)).
>>
>> Is JSON the only real possible format? Probably, at least for
>> compatibility with pretty much everything that exists. Only TJSON could
>> maybe be used as an alternative (and kind of removes the need for a
>> schema), with the downsides that you don't have so many existing libraries
>> and that the community seems much smaller: 2k stars for JSON schema spec vs
>> 65 for TJSON spec (and the expired website SSL certificate doesn't help).
>>
>> The main problem I see is that for constrained cases, CBOR won't have a
>> schema in a foreseeable future (at least I'm not aware of any work on
>> that). I know it's not our main focus right now and might not even be
>> covered by the current WG, but still it might become an issue at some
>> point.
>>
>> Best,
>> Fabien
>>
>> On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer <[e-mail]>
>> wrote:
>>
>>> Hi Fabien,
>>>
>>>
>>>
>>> One correction, JSON Schema (which I am personally advocating for, but
>>> still) does not have an IETF spec. They claim on their web site that they
>>> want it standardized, but in practice are not (yet?) moving in this
>>> direction. Their Internet Draft is unmaintained.
>>>
>>>
>>>
>>> At a higher level, I think your discussion conflates two things: the
>>> representation of data on the wire (JSON or various mostly binary
>>> encodings) and the data modeling language, a.k.a. schema. Personally I
>>> think JSON is almost a must in our case, and if this is true, the playing
>>> field is **much** more narrow.
>>>
>>>
>>>
>>> A major strength of JSON which you don’t mention in your comparison is
>>> the cryptographic ecosystem (JOSE): standard formats for encryption,
>>> signature etc.
>>>
>>>
>>>
>>> I wasn’t aware of Ion. I don’t think it’s a good fit for us, still a
>>> very interesting direction.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>                 Yaron
>>>
>>>
>>>
>>> *From: *Fabien Imbault <[e-mail]>
>>> *Date: *Friday, October 30, 2020 at 14:53
>>> *To: *Andrii Deinega <[e-mail]>
>>> *Cc: *Mika Boström <[e-mail]>, Justin Richer <
>>> [e-mail]>, Yaron Sheffer <[e-mail]>, GNAP Mailing
>>> List <[e-mail]>, Dick Hardt <[e-mail]>
>>> *Subject: *Re: [GNAP] Feedback on polymorphism
>>>
>>>
>>>
>>> Hi Justin,
>>>
>>>
>>>
>>> > Regarding your question, what else could we propose?
>>>
>>>
>>>
>>> I've started a review of possibilities at
>>> https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md
>>> to be followed by actual code testing.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Fabien
>>>
>>>
>>>
>>> On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega <[e-mail]>
>>> wrote:
>>>
>>> Hi Mika, Justin, and WG,
>>>
>>>
>>>
>>> The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange)
>>> has a JSON object as its value. This claim could be a part of AT JWT or a
>>> token introspection response and has the same semantics in both cases. The
>>> JSON object as its value may look like this
>>>
>>> "act":
>>> {
>>>   "sub":"[e-mail]"
>>> }
>>>
>>> or even be nested like in
>>>
>>> "act":
>>> {
>>>  "sub":"https://service16.example.com",
>>>    "act":
>>>    {
>>>      "sub":"https://service77.example.com"
>>>    }
>>> }
>>>
>>> Personally, I find it to be a very expressive approach. Also, as far I
>>> as know, several (oAuth2) client libraries have good support of things like
>>>
>>> "aud":"https://service1.example.com" and "aud":["
>>> https://service1.example.com","https://service2.example.com"]
>>>
>>> in AT JWTs for a quite long time.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Andrii
>>>
>>>
>>>
>>> On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault <
>>> [e-mail]> wrote:
>>>
>>> Hi Yaron,
>>>
>>>
>>>
>>> We'll indeed have to check how make it as idiomatic as possible with
>>> experts of each language (help welcome).
>>>
>>>
>>>
>>> Regarding the client, the variations are more limited but they do exist.
>>> Here I believe it's much more problematic than on the server side and there
>>> are at least a few actions we should take:
>>>
>>>
>>>
>>> A) check in sec 7 if we really have a compelling reason for key and
>>> proof variants. This is derived from larger discussions on key binding as
>>> per the related note. There are quite a few open questions related to this
>>> theme.
>>>
>>>
>>>
>>> B) there is also the choice between value/reference that may generate
>>> complexity.
>>>
>>>
>>>
>>> C) More generally, as many feedbacks already have noticed, we need to
>>> have a systematic review and reduce the set of available options in the
>>> protocol.
>>>
>>>
>>>
>>> Unless we have a clear idea why runtime behavior requires mutability, it
>>> might be useful to have a way to define the chosen variant before hand, so
>>> that the expected behavior becomes deterministic on the client side. There
>>> are various ways it could be done in practice.
>>>
>>>
>>>
>>> For sure several independant implementations would help, especially if
>>> we make sure they can work together.
>>>
>>>
>>>
>>> Anyway all this open to improvement.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Fabien
>>>
>>>
>>>
>>> Le mer. 28 oct. 2020 à 19:47, Yaron Sheffer <[e-mail]> a
>>> écrit :
>>>
>>> Hi Fabien,
>>>
>>>
>>>
>>> At least in the case of Go, I think the “solution” is far worse than the
>>> problem. The code in the article you cite is very specific to the use case
>>> and IMHO quite ugly. So my preferred Go implementation would be a
>>> combination of untyped structures (Go interface{}) and run-time enforcement
>>> of JSON Schema.
>>>
>>>
>>>
>>> Also, going back to our earlier discussion on this topic, I just read
>>> Sec. 7 of gnap-00 and realized that the RC also needs to deal with
>>> polymorphism (the “key” value), not only the AS.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>                 Yaron
>>>
>>>
>>>
>>> *From: *TXAuth <[e-mail]> on behalf of Fabien Imbault <
>>> [e-mail]>
>>> *Date: *Wednesday, October 28, 2020 at 18:56
>>> *To: *Mika Boström <[e-mail]>
>>> *Cc: *GNAP Mailing List <[e-mail]>, Justin Richer <
>>> [e-mail]>, Dick Hardt <[e-mail]>
>>> *Subject: *Re: [GNAP] Feedback on polymorphism
>>>
>>>
>>>
>>> Thanks for the great feedback. Your concern is very valid.
>>>
>>>
>>>
>>> My implementation is in rust, which makes life easier in that specific
>>> case.
>>>
>>>
>>>
>>> So I'm not a golang specialist but I guess the transcription of json
>>> strings/arrays into go structs would work around the lines described by
>>> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1
>>>
>>> When we have a more formalized json schema, I suggest we make a library
>>> of json examples and some related code samples in mainstream languages, to
>>> check it is feasible for everyone.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Fabien
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 28, 2020 at 5:28 PM Mika Boström <[e-mail]>
>>> wrote:
>>>
>>> Hi everyone,
>>>
>>>
>>>
>>> Looks like I stuck my finger in a hornets' nest. First off, apologies
>>> for not chipping in earlier, but there was a lot of material to digest.
>>> Also, warning: lots to read ahead.
>>>
>>>
>>>
>>> I'm one of those people who end up making use of AuthN/AuthZ
>>> functionality through a library. On top of that I can see myself being
>>> roped in as a server (AS) implementation help. So I'm approaching this from
>>> an outsider's perspective. Someone who expects to be exposed to the
>>> eventual RFC and all the nitty-gritty details. My relatively terse comment
>>> ended up at the top of the aforementioned HN thread, which didn't
>>> necessarily help. Sorry about that.
>>>
>>>
>>>
>>> Now, having read Justin's initial reply - and the rest of the thread - I
>>> believe I can see where the desire for polymorphism comes from. To be
>>> clear: I am all for strict types inside an implementation, as it will add
>>> helpful guard-rails to the state management code paths. However, I see this
>>> as a case of leaky abstraction. If we take the existing oauth.xyj-java code
>>> to be the reference implementation, the choice makes logical sense: JSON is
>>> not expressive enough to serialise arbitrary objects, so in order to avoid
>>> writing complex payload parser(s) the internal implementation details now
>>> leak to the protocol itself. From a purely technical perspective, it's a
>>> cool trick. From a distance it even looks a bit like the result of protobuf
>>> decoding, but without the generated code parts.
>>>
>>>
>>>
>>> But then the downside. I don't personally expect to be able to use the
>>> reference implementation, being mostly a Python user myself. A fair number
>>> of AS implementations will be written with languages such as Go, Python,
>>> C#, Ruby, and JavaScript (thanks to node.js), and all of them will have to
>>> deal with the polymorphism. From what I've read over the past couple of
>>> days, I understand that at least Go supports custom unmarshalers from JSON
>>> to typed structs, at the cost of an indirection. Normally when a Go code
>>> processes JSON to a typed struct, the process is helped by field
>>> annotations in the type definition itself. For example, if the payload for
>>> a person in JSON was
>>>
>>>
>>>
>>> {
>>>
>>>   "name": "<string>",
>>>
>>>   "age": <int>,
>>>
>>>   "country": "<string>",
>>>
>>>   "city": "<string>"
>>>
>>> }
>>>
>>>
>>>
>>> .. then the type definition would look like:
>>>
>>>
>>>
>>> type Person struct {
>>>
>>>   Name string `json:"name"
>>>
>>>   Age int `json:"age"`
>>>
>>>   Country string `json:"country"`
>>>
>>>   City string `json:"city"`
>>>
>>> }
>>>
>>>
>>>
>>> When the (possibly complex) type of a given field is fixed, unmarshaling
>>> should still be straightforward. I haven't verified, but since the
>>> annotation only gives which field to look at for a given typed value, there
>>> should be nothing special about that. But when the field can instead be a
>>> union of more than one distinct types, things start to get messy. There is
>>> no union type in the language at all, so the following construct is not
>>> even possible:
>>>
>>>
>>>
>>> type Entity struct {
>>>
>>>   Resources []string `json:"resources"`
>>>
>>>   Client union(Client, string) `json:"client"`
>>>
>>> }
>>>
>>>
>>>
>>> As I understand, the implicit expectation is that in the above case, the
>>> unmarshaler detects that "client" is a string, and so expands it from an
>>> opaque handle to the expected, populated type. Even after thinking about
>>> the ramifications over the past few days I remain confused, because I don't
>>> see how the commonly used annotations could work. If the expectation is
>>> that protocol implementations should use strong types, then the use of
>>> polymorphic JSON is very likely to make things _more_ complicated for
>>> non-reference implementations.
>>>
>>>
>>>
>>> Hence my concern. I'm afraid that the leaky abstraction, while making
>>> the reference implementation more robust and straightforward, contributes
>>> to making other implementations less robust. And this being a security
>>> protocol, the potential for brittle and/or confused implementations is
>>> terrifying.
>>>
>>>
>>>
>>> I am a fan of reducing complexity, and from what I can see, for the
>>> reference implementation the polymorphic approach actually does that. But
>>> I'm afraid it does so at others' expense. Languages have their individual
>>> constraints, idioms and best practices. If parsing a protocol payload
>>> introduces low-level complexities and encourages to go against common
>>> practices, that is an invitation for problems. I am aware that my choice of
>>> words in the HN thread was likely to put people on defense, and for that I
>>> apologise. But I do believe that the choice of polymorphic JSON is going to
>>> make the life and use of other implementations notably less boring than
>>> people in general would prefer.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Mika
>>>
>>>
>>>
>>> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>> Hi Dick,
>>>
>>>
>>>
>>> Well technically yes. Obviously the client can present any interface it
>>> seems fit.
>>>
>>>
>>>
>>> Still there's the question of the common model we want to present to the
>>> outside world and supported by the protocol itself (which client libraries
>>> all build upon).
>>>
>>>
>>>
>>> But beneath the polyphormism question, the HN debate seems on the
>>> surface a lot like the original xyz (polyphormism goes along with the
>>> reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and
>>> where the client design has more latitude). Just explained differently, by
>>> outside people with different agendas.
>>>
>>>
>>>
>>> Which is a bit weird because many of the critics on HN (who criticize
>>> polyphormism) also seem to really dislike OAuth in the first place (the
>>> inconsistencies are partially due to a bunch of different people
>>> commenting).
>>>
>>>
>>>
>>> Really to me there's no fundamental truth behind that question. It's a
>>> matter of preference and priorities in the design. Whatever choices we
>>> make, we'll have to be prepared to explain and justify them in the open,
>>> even to some people that will dislike pretty much whatever we do (because
>>> it's fun to look smart and critize without proposing alternatives). And we
>>> owe these answers to people like Mika, who genuinely try to make the best
>>> of it.
>>>
>>>
>>>
>>> Fabien
>>>
>>>
>>>
>>> Le lun. 26 oct. 2020 à 00:58, Dick Hardt <[e-mail]> a
>>> écrit :
>>>
>>> Hi Fabien
>>>
>>>
>>>
>>> A library developer can provide whatever abstraction layer makes sense
>>> for the library's target audience and language.
>>>
>>>
>>>
>>> If the client library developer wants to use polymorphism in the
>>> interface presented to the user's of the library, the library developer can
>>> do that independent of polymorphism in the protocol, and vice versa
>>>
>>>
>>>
>>> => polymorphism in the protocol has no impact on client library
>>> developers
>>>
>>>
>>>
>>>
>>>
>>> *Error! Filename not specified.*ᐧ
>>>
>>>
>>>
>>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>> I'm just realizing your "least to most important" might actually say the
>>> same as what I was trying to say. So I'm not even sure what we're arguing
>>> against :-)
>>>
>>>
>>>
>>> In brief my point if it wasn't clear is that we should be crystal clear
>>> on where we put the cursor of simplicity, because this can mean different
>>> things for different people and different roles.
>>>
>>> And as we see on HN we need to better explain our design choices.
>>>
>>>
>>>
>>>
>>>
>>> Le dim. 25 oct. 2020 à 00:25, Fabien Imbault <[e-mail]>
>>> a écrit :
>>>
>>> Hi Dick,
>>>
>>>
>>>
>>> Independantly from the debate on polyphormism, I beg to differ on your
>>> order preference.
>>>
>>>
>>>
>>> Your assumption is that AS devs matter the most, because they're doing
>>> the important security implementation. But eating our own dogfood might
>>> help a lot to change that view. Most security issues occur because users of
>>> the spec are unable to deal with the complexity that is passed onto them.
>>>
>>>
>>>
>>> 99% of the people that will actually use the output of the work are
>>> application developers (client or RS) and their own users.
>>>
>>>
>>>
>>> Our intent as well as the protocol drive the usage. Client libraries may
>>> help, but they're not a silver bullet, especially because GNAP ultimately
>>> has no control about what people do there (for better or worse). And
>>> everything we do here will help get to the better part.
>>>
>>>
>>>
>>> I'm not saying we don't intend to also care about AS developers
>>> (beginning with ourselves) but it's a second order optimisation. And since
>>> it's a tendancy we're leaning towards by default, I'm pretty sure we won't
>>> forget that anyway.
>>>
>>>
>>>
>>> Fabien
>>>
>>>
>>>
>>>
>>>
>>> Le sam. 24 oct. 2020 à 23:50, Dick Hardt <[e-mail]> a
>>> écrit :
>>>
>>> I'm confused by your logic Fabien.
>>>
>>>
>>>
>>> If a client library developer wants to expose polymorphism, they can do
>>> that independent of what is in the protocol.
>>>
>>>
>>>
>>> I differ on who our stakeholders are.
>>>
>>>
>>>
>>> I think our stakeholders are in least to most important:
>>>
>>>
>>>
>>>    - AS developer
>>>    - RS developer
>>>    - client developer
>>>    - user
>>>
>>>
>>>
>>> A client library developer can expose whatever interface they want to
>>> simplify implementation.
>>>
>>>
>>>
>>> I list the user so that we don't lose site of a critical role.
>>>
>>>
>>>
>>> /Dick
>>>
>>>
>>>
>>>
>>>
>>> *Error! Filename not specified.*ᐧ
>>>
>>>
>>>
>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>> Hi there,
>>>
>>>
>>>
>>> Let me try to approach the issue under a different light. More like a
>>> product manager would deal with feature selection to make it intuitive for
>>> its users.
>>>
>>>
>>>
>>> For most people, riding a bike is far easier than using a unicycle.
>>> Feels more stable. And yet it's way easier to design for a single wheel
>>> than to build with 2. Because then you'll need a lot more accessories
>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be a
>>> brittle process, it can be industrialized.
>>>
>>>
>>>
>>> Back to the GNAP topic.
>>>
>>> Ultimately we should strive to make the spec as simple as can be. But we
>>> need to ask: simple for whom? For the bike owner or for the bike vendor?
>>>
>>> (short answer: the priority should be simplicity for spec users, not
>>> spec implementers and even less spec designers).
>>>
>>>
>>>
>>> The initial question that is asked is very interesting: isn't the design
>>> flawed if GNAP is using json polyphormism? Or if the AS needs to handle the
>>> state of the request? Or if we must handle token revocation? Or if we are
>>> looking for a global unique identifier? The argument stems of the fact that
>>> is still arguably harder and more error prone to implement. Fair enough.
>>>
>>>
>>>
>>> From a spec implementer's perspective, it may well be more complex. It
>>> mostly impacts the json library you'll end up using, plus a bit of
>>> input/output decoration around it. Even golang provides utilities for this,
>>> despite not exactly being made for this kind of purpose.
>>>
>>> My practical experience implementing it is that it's not that big a
>>> deal. I mean, I wished it could be simpler, but it's manageable and there
>>> are other ways to reach levels of insurance that it does work as intended
>>> (json schema, test cases to validate the implementation, etc.). Arguably it
>>> is still easier from an implementation perspective than say, json-ld, which
>>> is massively used in the SSI community.
>>>
>>>
>>>
>>> But ultimately who are we designing for? Are we striving to go easy on
>>> the spec implementer? Or are we trying to make sure end-developers using
>>> the client libraries won't shoot themselves in the foot?
>>>
>>>
>>>
>>> The job to be done (JTBD), from the end-developer's perspective, is to
>>> efficiently ship an application. And provide authN/authZ capabilities for
>>> end-users by relying on some well known implementation.
>>>
>>> In turn, this spec implementer will rely on cryptographic utility
>>> libraries that deals internally with the complexity of their own domain, so
>>> that we don't have to. And here we could launch another HN flame war that
>>> starts with the title "JWT sucks because". Which does have its set of very
>>> real issues but that's beyond the point.
>>>
>>> Note that any decent flamewar will be efficiently fueled by people
>>> hating medium. Is it outrageous for blog posts to be behind a paywall?
>>> Maybe but it's even more outrageous to lack consistency, either by not
>>> knowing how to get around a paywall if you're into a hacker punk movement,
>>> or on the contrary by to not paying a subscription if you believe that
>>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated.
>>>
>>> What likely seems an unnecessary sidenote tries to illustrate the point:
>>> for Justin it was easier to publish on medium, because as a blog publisher,
>>> you might not want to deal with hosting your own blog. But maybe as a
>>> reader you'll find that annoying. Different audiences, different JTBD,
>>> different tradeoffs.
>>>
>>>
>>>
>>> Polyphormism is a tool that enables the end-developer to have minimal
>>> knowledge of what it means to deal with a GNAP client library. You prepare
>>> the request, send to the endpoint and you're good to go. Massively simpler
>>> than OAuth2 or any similar protocol by the way (as anyone with teaching
>>> experience on the subject might acknowledge). And  there's a lot more to be
>>> done to make sure we indeed reduce the complexity for the end-developer and
>>> the end-user.
>>>
>>>
>>>
>>> If we find a better way to deal with that simplicity balance, I'm all
>>> in. But the arguments need to be way more convincing than just saying that
>>> it may be difficult to implement or validate.
>>>
>>>
>>>
>>> Cheers.
>>>
>>> Fabien
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Le ven. 23 oct. 2020 à 22:35, Justin Richer <[e-mail]> a écrit :
>>>
>>>
>>>
>>>
>>>
>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt <[e-mail]> wrote:
>>>
>>>
>>>
>>> Justin
>>>
>>>
>>>
>>> I did note that I was the one that argued for instance_id being in the
>>> object. Since it is in the object in the current draft, not including a
>>> pass by reference option would be preferable.
>>>
>>>
>>>
>>> As for concrete examples:
>>>
>>> - version of client
>>>
>>> - version of OS
>>>
>>> - security attestation of OS / device
>>>
>>> - location of client device
>>>
>>> - network client is operating on
>>>
>>>
>>>
>>> These are all attributes of the client that an AS may require on the
>>> initial grant request, and in future grant requests (which is when an
>>> instance_id) would be used.
>>>
>>>
>>>
>>>
>>>
>>> This is where our interpretations differ: I don’t see these as
>>> “attributes of the client” in the same way that the key, display
>>> information, class identifiers, and other items currently represented by an
>>> instance_id are attributes of the client instance. The attestation
>>> components don’t modify the instance so much as present additional
>>> information on top of the client instance itself. This is why I argue that
>>> they ought to be handled in a separate object, so you’d have something like
>>> this strawman:
>>>
>>>
>>>
>>> {
>>>
>>>
>>>
>>>   posture: {
>>>
>>>     software_version: 1.2.3,
>>>
>>>     os_version: 14.3.2
>>>
>>>     device_attestation: { … some structure or signed blob? … }
>>>
>>>     location: { lat: …, lon: …, alt: … }
>>>
>>>   },
>>>
>>>
>>>
>>>   client: “client-541-ab"
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>> This is a more fundamental question about GNAP than whether the syntax
>>> uses polymorphism: this is about GNAP being very explicit about the data
>>> model of its elements. OAuth 2’s incredibly loose and broad model of what
>>> the term “client” is referring to, exactly, is deeply problematic in
>>> practice. We’re even seeing that in the OAuth 2.1 work with having to
>>> define a “credentialed client”, and even then that doesn’t fully capture
>>> the different aspects that are out there. I think we’re getting closer here
>>> in GNAP with explicit definition of “client instance”, but we still need to
>>> be more precise about what exactly a client instance includes, and what it
>>> does not.
>>>
>>>
>>>
>>>  — Justin
>>>
>>>
>>>
>>>
>>>
>>> /Dick
>>>
>>>
>>>
>>> *Error! Filename not specified.*ᐧ
>>>
>>>
>>>
>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <[e-mail]> wrote:
>>>
>>> Dick,
>>>
>>>
>>>
>>> As you’ll recall, I argued against including the client instance
>>> identifier inside of the object as a mutually-exclusive field precisely
>>> because of the principle violation that you are pointing out here, and so
>>> it’s important to point out that the current text is a compromise that
>>> needs to be examined in the wider experience of the working group. I am on
>>> the side of removing the mutually-exclusive “instance_id” option within an
>>> object, but this needs to be explored.
>>>
>>>
>>>
>>> The crux of my argument is that is exactly a case of pass-by-reference
>>> vs pass-by-value, and that runtime attestations are not part of the “client
>>> instance” value itself but rather belong outside of that object in a
>>> another part of the request. As stated in the editorial notes in this
>>> section, we need to look carefully at how these concepts fit within the
>>> model and where we would want to put them. Without concrete examples of
>>> what these extensions look like and how they’re generated, that is nearly
>>> impossible to do at this stage. I look forward to seeing examples of this
>>> kind of data and how it can fit into the protocol.
>>>
>>>
>>>
>>>  — Justin
>>>
>>>
>>>
>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt <[e-mail]> wrote:
>>>
>>>
>>>
>>> Hey Justin,
>>>
>>>
>>>
>>> As the draft has evolved, I question the continued use of polymorphism.
>>> Note that I appreciate the elegance of using a string for
>>> pass-by-reference, and an object for pass-by-value.
>>>
>>>
>>>
>>> In the current draft, the
>>>
>>>
>>>
>>> Every time you create or process a field it will mean only one thing,
>>> and there’s only one field to look at to answer a question.
>>>
>>>
>>>
>>> is violated in 2.3.1.  Identifying the RC Instance
>>> <https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-00#section-2.3.1>
>>>
>>>
>>>
>>>
>>>
>>>    instance_id  An identifier string that the AS can use to identify the
>>>
>>>       particular instance of this RC.  The content and structure of this
>>>
>>>       identifier is opaque to the RC.
>>>
>>>
>>>
>>>    "client": {
>>>
>>>        "instance_id": "client-541-ab"
>>>
>>>    }
>>>
>>>
>>>
>>>    If there are no additional fields to send, the RC MAY send the
>>>
>>>    instance identifier as a direct reference value in lieu of the
>>>
>>>    object.
>>>
>>>
>>>
>>>    "client": "client-541-ab"
>>>
>>>
>>>
>>> The instance identifier can be sent two ways. Polymorphism is a
>>> convenience for the client, but requires the server to have two code paths
>>> for "instance_id".  We discussed this in the design team, and I argued for
>>> having "instance_id" in the "client" object so that any updates, such as
>>> new devices assertions, could be in the "client" object. As noted above,
>>> while I appreciate the elegance of using a string (handle) to reference a
>>> previously provided object, it complicates how to update an existing object
>>> while providing the reference.
>>>
>>>
>>>
>>> In your example of the "key" object below, setting "proof" to bearer
>>> would avoid the issue you describe:
>>>
>>>
>>>
>>> {
>>>  "key": {
>>>      "proof": "bearer"
>>>     }
>>> }
>>>
>>>
>>>
>>> In your example, when processing the "key" object, code is having to
>>> check both the JSON type of the property, as well as check the value of the
>>> "proof" property. In the example I provided, only the value of "proof"
>>> needs to be checked. The "proof" property is acting as a type for the "key"
>>> object.
>>>
>>>
>>>
>>> Not being a Java programmer, I don't know how this would work in a Java
>>> implementation, but node.js, the processing would need to be done as above.
>>>
>>>
>>>
>>> On a related note, there was significant negative feedback on handles
>>> and polymorphism in the Hacker News article
>>> https://news.ycombinator.com/item?id=24855750
>>>
>>>
>>>
>>> /Dick
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <[e-mail]> wrote:
>>>
>>> Hi Mika,
>>>
>>>
>>>
>>> Thanks for bringing this topic here — I was able to see the forum
>>> discussion that brought you here, and hopefully I can help clear up what I
>>> mean with how polymorphism is used in the proposal. The short version is
>>> that the goal is to *avoid* the kinds of ambiguity that make insecure
>>> protocols, and so in that goal we’re fully aligned. I think that using
>>> polymorphism in very specific ways can help that goal — just as I agree
>>> that misusing it or applying it sloppily can lead to ambiguous and insecure
>>> systems.
>>>
>>>
>>>
>>> Some background: I built out the XYZ protocol (one of the predecessors
>>> to the initial GNAP Draft) in Java using strongly typed parsers and Java
>>> objects specifically to prove to myself that it could be done in a way that
>>> made any sense in the code. (My own open source implementation is at
>>> https://github.com/bspk/oauth.xyz-java, but note that it’s not yet up
>>> to date with the GNAP spec). It was important to me that I be able to use
>>> the system-wide configured parsers to implement this and not have to resort
>>> to stepping through elements completely by hand. Java doesn’t make it
>>> simple to get the hooks into the right places (especially with the Jackson
>>> parser that I used), but it is definitely possible to create a
>>> deterministic and strongly-typed parser and serializer for this kind of
>>> data structure. Some of the rationale for using polymorphism is covered in
>>> the trailing appendix of the draft document (
>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polymor),
>>> but it’s still good to discuss this here as the working group decides which
>>> approaches to take.
>>>
>>>
>>>
>>> The driving reason for using polymorphism at the protocol level was to
>>> simplify the protocol and make it :more: deterministic to create and
>>> process, not less. Every time you create or process a field it will mean
>>> only one thing, and there’s only one field to look at to answer a question.
>>> Without polymorphic field values, you usually need to rely on mutual
>>> exclusivity of fields, which is prone to failure and requires additional
>>> error checking. Take for example the key binding of access tokens. An
>>> access token could be bound to the RC’s key used during the request, to a
>>> different key chosen by the AS, or it could be a bearer token with no key
>>> at all. By making the “key” field polymorphic, we can define it in terms of
>>> boolean values and objects and express this set of mutually-exclusive
>>> options in a non-ambiguous way. Without that, you’d need to have different
>>> fields for the options and include additional checks in your parser to make
>>> sure they weren’t sent simultaneously, otherwise you could get hit with
>>> this potential security vulnerability in an object:
>>>
>>>
>>>
>>> {
>>>
>>>     key: {
>>>
>>>       proof: httpsig,
>>>
>>>       jwk: { … key value … }
>>>
>>>     },
>>>
>>>     bearer_token: true,
>>>
>>>     bind_to_rc_key: true
>>>
>>> }
>>>
>>>
>>>
>>> This would be an illegal object as per this alternate proposal, but then
>>> you’d have to check each field and make sure it wasn’t put next to others
>>> in the same object. I’ve done this exercise with many other protocols and
>>> it’s both error prone and easy to ignore since all the “good” examples
>>> would pass code that doesn’t check this. With the polymorphic approach to
>>> this same field, each of these three mutually-exclusive states is written
>>> in a way that they cannot be sent together. It’s not just illegal, it’s
>>> impossible and enforced by the syntax of JSON itself.
>>>
>>>
>>>
>>> {
>>>
>>>     key: {
>>>
>>>       proof: httpsig,
>>>
>>>       jwk: { … key value … }
>>>
>>>     }
>>>
>>> }
>>>
>>>
>>>
>>> // bearer token
>>>
>>>
>>>
>>> {
>>>
>>>     key: false
>>>
>>> }
>>>
>>>
>>>
>>> // bound to the RC’s presented key
>>>
>>>
>>>
>>> {
>>>
>>>     key: true
>>>
>>> }
>>>
>>>
>>>
>>> If someone sends a different type for this field, like an array or
>>> number or a null, this doesn’t have a defined interpretation in the
>>> protocol and would be a protocol level error.
>>>
>>>
>>>
>>> While it might sound like polymorphism means that any field could have
>>> any type or value, the opposite is true: each possible value is explicitly
>>> typed, it’s just that there are potentially different types that express
>>> meaning for the field. This applies to all members of all objects
>>> (dictionaries) as well as all members of an array (list). Every time you
>>> process a field value or other element, you look at the type and then the
>>> value to determine what to do with that typed value.
>>>
>>>
>>>
>>> In your example below, each field within the dictionary would also need
>>> to be typed, and each type would need to have a clear indication of its
>>> meaning. To take your strawman key format below, the “modulus” field could
>>> be defined polymorphically as either a “bigint” (a JSON number) or an
>>> “encoded string” (a JSON string). The definition would further say what
>>> exactly the encoding of the string would be. That means that when you read
>>> the “modulus” field there wouldn’t be any confusion on what the value was
>>> or how it was represented, regardless of the input format. Seeing a number
>>> there means exactly one interpretation and seeing a string means exactly
>>> one (different) interpretation — but importantly, both of them are a
>>> “modulus”, since that’s the field that determines the type. An
>>> implementation would likely use an internal BigInteger type of object to
>>> represent the field value after parsing, so the question is how to go from
>>> the JSON value (which is typed) into the BigInteger value.You don’t just
>>> apply the type rules on the “public_key” field, you apply it to all
>>> sub-fields of that object.
>>>
>>>
>>>
>>> So let’s dig into the specific bug you bring up in the strawman, because
>>> it’s interesting: A JSON encoder that encodes numbers as strings, and not
>>> numbers, is not compliant with the JSON definitions of the field in
>>> question. For another example, the quoted string value of “true” is not
>>> equivalent to the boolean value true in JSON, and they shouldn’t be treated
>>> the same by a parser implementation when mapping to a concrete object. It’s
>>> in this kind of automated guessing that this class of bugs occur, and
>>> that’s going to be the case whether or not you take  advantage of JSON’s
>>> polymorphic nature. I’ve run into cases where a parser library was trying
>>> to be overly “helpful” in doing this kind of mapping, but ended up
>>> introducing errors in more strict components downstream. This is something
>>> that protocol designers need to be aware of and guard against in the design
>>> of the protocol to reduce possible ambiguities. Within GNAP today, we
>>> generally have things that branch whether they’re an object (for a rich
>>> description of something) or some non-structured special value (for a
>>> reference or other item).
>>>
>>>
>>>
>>> The design team created some simple JSON Schemas for parts of the
>>> protocol during our discussion, but we didn’t include them in the design
>>> document due to both lack of time to keep it updated with the rapid changes
>>> to the protocol during the design team discussion, and not knowing if there
>>> would be interest in such material. I personally think it would be helpful
>>> to include as an informative reference in the final document, but that’s
>>> something for the working group to take up eventually.
>>>
>>>
>>>
>>>  — Justin
>>>
>>>
>>>
>>> On Oct 23, 2020, at 10:18 AM, Mika Boström <
>>> mika.bostrom=[e-mail]> wrote:
>>>
>>>
>>>
>>> Hello, everyone.
>>>
>>>
>>>
>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and
>>> when I made note about certain concerns, I was requested to send my
>>> comments to this working group.
>>>
>>>
>>>
>>> In short, I believe that the use of polymorphic JSON in the protocol
>>> invites subtle and confusing implementation problems. I also searched
>>> through the WG archives, and noticed that similar concerns were noted,
>>> briefly, in a thread in July.
>>>
>>>
>>>
>>> The problem with polymorphic values, as I see it, is that
>>> implementations will need to branch on the (inferred) type of a given
>>> field. This isn't quite as bad if the types are strictly different, but
>>> allows for subtle bugs when the value in question is a dictionary. What
>>> makes this unappealing is that "subtle bugs" in security protocols have a
>>> habit of turning into vulnerabilities.
>>>
>>>
>>>
>>> Let's say we have these imaginary payloads, both possible and valid in
>>> the same protocol step:
>>>
>>>
>>>
>>> # payload 1
>>>
>>> {
>>>
>>>   ...,
>>>
>>>   "public_key": {
>>>
>>>     "alg": "rsa",
>>>
>>>     "modulus": <BIGINT>
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> # payload 2
>>>
>>> {
>>>
>>>   ...,
>>>
>>>   "public_key": {
>>>
>>>     "alg": "rsa",
>>>
>>>     "modulus": "<encoded string>"
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> In both cases, the type of "public_key" field is a dictionary. In both
>>> cases, they even have the same keys. However, the values in the
>>> dictionaries are entirely different, and an implementation will have to
>>> branch to at least two possible decoding mechanisms. To make things worse,
>>> some JSON implementations may choose to encode non-dictionary values as
>>> strings, so it is possible for an originator to transmit what they expect
>>> and believe to be payload 1 format, but which the receiver will interpret
>>> to be in payload 2 format. And if the encoded string contains only digits,
>>> it will even parse correctly as a bignum.
>>>
>>>
>>>
>>> While the above is clearly a manufactured scenario, it nonetheless
>>> demonstrates the potential for logic bugs with polymorphic JSON. With
>>> richer types and more complex dictionaries, there will surely be more room
>>> for errors.
>>>
>>>
>>>
>>> Ambiguity in protocols is always a source of implementation complexity
>>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse:
>>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't
>>> it be in everyone's interest to keep implementation complexity and mistake
>>> potential to a minimum?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Mika
>>>
>>>
>>>
>>> --
>>>
>>> Mika Boström
>>>
>>> Smarkets
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>> *Error! Filename not specified.*ᐧ
>>>
>>>
>>>
>>>
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>>> --
>>>
>>> Mika Boström
>>>
>>> Smarkets
>>>
>>> -- TXAuth mailing list [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>