Re: [GNAP] Feedback on polymorphism

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> *Date: *Sunday, October 25, 2020 at 12:39
> *To: *Yaron Sheffer <[e-mail]>
> *Cc: *Dick Hardt <[e-mail]>, Mika Boström <mika.bostrom=
> [e-mail]>, GNAP Mailing List <[e-mail]>,
> Justin Richer <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> on behalf of Fabien Imbault <
> [e-mail]>
> *Date: *Sunday, October 25, 2020 at 01:25
> *To: *Dick Hardt <[e-mail]>
> *Cc: *Mika Boström <mika.bostrom=[e-mail]>, GNAP
> Mailing List <[e-mail]>, Justin Richer <[e-mail]>
> *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 <[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
>
> -- TXAuth mailing list [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>