Re: [GNAP] Feedback on polymorphism

I want to point out that JSON schema can enforce mutually exclusive
properties.

For example the "client" object containing once of "instance_id",
"class_id", or "display"

ᐧ

On Sun, Oct 25, 2020 at 9:33 AM Justin Richer <jricher@mit.edu> wrote:

> I agree fully with Fabien’s statements on who we’re making things easy
> for. If this security protocol isn’t easy and straightforward for client
> developers — with or without a library — then it simply will not be
> adopted. It might be hard to see when looking at the whole protocol, but
> this goal is actually one of the drivers for the way polymorphism is used
> in the current draft. The driving philosophy of OpenID Connect’s
> development was “keep the simple things simple, make the complex things
> possible”, and that’s a philosophy I strongly believe we need to continue
> here in GNAP.
>
> Importantly, a client developer shouldn’t need to have to support all
> possible permutations in order to get something right. OAuth has shown us
> that even when a protocol has a lot of options, client software is going to
> be coded to use only one set of options. If the protocol can support that
> reality, I think we are doing well. In the current draft, generally
> speaking it’s the AS that needs to handle different options, not the
> client. Take for example requesting resources: a very simple client might
> just send an array of strings, like OAuth scopes. The AS needs to be able
> to handle the string inputs as well as the rich object descriptors, but the
> client software doesn’t even need to know that the object format exists in
> order to create compliant JSON.  The client developer can do this without
> any special libraries, it can just bang out the JSON directly. Such a
> client won’t be able to do the more fancy stuff that the request objects
> allow, but for this client, that’s fine since all it needs to do is produce
> an array with strings that the AS will accept. The same is true across the
> various other options, like requesting multiple access tokens vs a single
> one, or providing an instance identifier vs. a set of information for the
> client instance itself. Client developers should be fully able to ignore
> parts of the protocol that they aren’t using, especially the more advanced
> stuff. An AS shouldn’t get to have such a choice, but as the AS is the
> lynchpin of the security model, I am OK with things being slightly more
> complex to support, especially if it shifts that complexity away from
> clients.
>
> I am in favor of including JSON Schema in the draft in a non-normative
> way, and you can see an earlier version of that experiment that Fabien and
> I undertook as part of the Design Team. The schema will be available for
> developers who want to / can use it, but even for people who aren’t using
> the schema directly it can provide additional context and information. I am
> willing to put some cycles into creating schemas for the main request and
> response messages and put those into a pull request to create an appendix
> in the draft. I’d also be fine with a non-normative JSON-LD reference for
> LD processors — but (1) I’m not going to write that :) and (2) it can’t be
> required for the protocol to be understood.
>
>  — Justin
>
> On Oct 25, 2020, at 8:47 AM, Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
> Hi Yaron,
>
> As Justin explained that's the kind of idea we tested. For instance
> https://github.com/fimbault/test_gnap_schema (in rust).
>
> Cheers
> Fabien
>
> Le dim. 25 oct. 2020 à 13:36, Yaron Sheffer <yaronf.ietf@gmail.com> a
> écrit :
>
>> Personally, I would support polymorphism in the protocol if it (the RFC)
>> came with a well-defined JSON Schema [1] document, so a recipient can
>> automatically validate incoming messages at run-time. I would expect
>> senders to also validate messages as part of their testing. It’s not an
>> ideal solution, because:
>>
>>
>>
>>    - Some people at the IETF don’t like JSON Schema, for various reasons.
>>    - JSON Schema is not a standard, so it’s painful to require it
>>    normatively.
>>    - Even if it’s normative, some recipients will not validate messages
>>    anyway.
>>
>>
>>
>> This would be shifting some of the complexity from the library developer
>> to the spec developer, which is the right thing to do IMO.
>>
>>
>>
>> Thanks,
>>
>>                 Yaron
>>
>>
>>
>> [1] https://json-schema.org/
>>
>>
>>
>>
>>
>> *From: *Fabien Imbault <fabien.imbault@gmail.com>
>> *Date: *Sunday, October 25, 2020 at 12:39
>> *To: *Yaron Sheffer <yaronf.ietf@gmail.com>
>> *Cc: *Dick Hardt <dick.hardt@gmail.com>, Mika Boström <mika.bostrom=
>> 40smarkets.com@dmarc.ietf.org>, GNAP Mailing List <txauth@ietf.org>,
>> Justin Richer <jricher@mit.edu>
>> *Subject: *Re: [GNAP] Feedback on polymorphism
>>
>>
>>
>> Hi Yaron,
>>
>>
>>
>> Thanks for the feedback.
>>
>>
>>
>> Regarding client libraries, I think we can indeed learn a great deal from
>> cryptographic libraries. Cryptographic design provides a great amount of
>> flexibility for the specialists (including many parameters that you really
>> need to get right). We might think this is great to provide options but it
>> actually increases the cognitive load of library users.
>>
>>
>>
>> Look instead at what Google has provided with tink as an alternative and
>> you'll see it is a much easier way for cryptographic engineers (who aren't
>> cryptographers) to avoid mistakes or misuses.
>>
>>
>>
>> That's the *security* issue I'm referring to (not the fact that being
>> open they're tasty targets, although that may be related in some cases).
>> And tink is the kind of design we should be trying to achieve.
>>
>>
>>
>> I agree that it should be applicable to a wide range of well known
>> programming tools, including the likes of java and go.
>>
>> But I don't really see a limitation here. Might not be the most idiomatic
>> feel, but it can be made to work.
>>
>>
>>
>> Just so I understand, what alternatives would you prefer to polymorphism?
>> I can suggest json-ld but even Justin will Teel you it's even more complex
>> :-)
>>
>>
>>
>> Cheers
>>
>> Fabien
>>
>>
>>
>> Le dim. 25 oct. 2020 à 11:17, Yaron Sheffer <yaronf.ietf@gmail.com> a
>> écrit :
>>
>> Hi Fabien,
>>
>>
>>
>> I think your product management model has a lot of merit, but it does not
>> capture the security issue well.
>>
>>
>>
>> I agree that as we look at different customer personas, the “end user”
>> (the developer that’s using the libraries) should be our highest priority.
>> But I disagree about end-user mistakes being the top **security** issue.
>> Libraries are often open source in our space and used very widely. So they
>> make for tasty targets, and people are attacking them and are still finding
>> security issues in libraries that we’ve been talking about forever [1].
>>
>>
>>
>> (Yes, my example is actually an app flaw, but I think it could have been
>> prevented by a better designed library.)
>>
>>
>>
>> In other words, we do need to care about how easy it is to implement the
>> protocol correctly by **library** developers. From Justin describing his
>> own experience and other people on the thread that Dick referred to, I
>> would say that JSON polymorphism is painful for Java and Go developers.
>> With all due respect, I care about them much more than I care about
>> Haskell, as many more implementations are likely to use these languages.
>>
>>
>>
>> Thanks,
>>
>>                 Yaron
>>
>>
>>
>> [1]
>> https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-app/
>>
>>
>>
>> *From: *TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault <
>> fabien.imbault@gmail.com>
>> *Date: *Sunday, October 25, 2020 at 01:25
>> *To: *Dick Hardt <dick.hardt@gmail.com>
>> *Cc: *Mika Boström <mika.bostrom=40smarkets.com@dmarc.ietf.org>, GNAP
>> Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
>> *Subject: *Re: [GNAP] Feedback on polymorphism
>>
>>
>>
>> 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 <dick.hardt@gmail.com> 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 <fabien.imbault@gmail.com>
>> 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 <jricher@mit.edu> a écrit :
>>
>>
>>
>>
>>
>> On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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 <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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=40smarkets.com@dmarc.ietf.org> 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
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>> *Error! Filename not specified.*ᐧ
>>
>>
>>
>>
>>
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>> -- TXAuth mailing list TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>