New Third Party package dependency Tavis.UriTemplates after migrating from Microsoft.Azure.ActiveDirectory.GraphClient

[CZEMacLeod]

Having recently migrated code from using Microsoft.Azure.ActiveDirectory.GraphClient to Microsoft.Graph due to the package being deprecated and the service being slowly discontinued as of 30th June 2023, I now find my code has a new third-party package dependency - Tavis.UriTemplates.

At a surface glance, the package looks okay, and has substantial tests and an Apache-2.0 licence, so I am not immediately worried about its performance or correctness. However, it seems odd, when MS are actively avoiding third-party package dependencies and/or using source generators for build time parsing etc., that this package is used here. That and that it is used directly without some sort of abstraction layer, especially in an abstractions package required at runtime.

Can someone shed some light on this situation, and the providence of the package?

As a note, as far as I can tell, neither the nuget package, nor the dll contain a digital signature for instance.

[baywet]

Thanks for using the Microsoft Graph SDK and for reaching out.

This is something we thought about for a while, and it's a common concern across languages kiota supports. On one hand we need support for URI template and we'd like to avoid creating yet another implementation. On the other, it's an external dependency which comes with its own set of risks. Arguably this is less of a problem with any other language than dotnet as we already have other third party dependencies.

Ideally the support for URL templates in .net would be native to the platform (under system.Uri), or provided by the dotnet team (e.g. Microsoft.UriTemplate or so). We had started discussions with the dotnet team without much success at the time.

This is why we encapsulated its use to a single place and we could easily swap it out if necessary in the future without causing a breaking change.

URL templates in general are described by the RFC 6570, so there is not much room for "interpretations" to begin with. This specific dependency is owned by @darrelmiller (Kiota's architect) which is started before he joined Microsoft. It's the most popular implementation in the .net ecosystem.

With that context in mind, I'd like to understand better what limitations this approach might be causing you?

[CZEMacLeod]

@baywet, Thanks for the update on this. I think I'm pretty happy with this, especially since you mention that the package author is directly involved in this project too.

My main concern is that that package is more 'susceptible' to attacks due to the lack of signatures.

I'm not entirely surprised that the dotnet team didn't want to take it directly under the main BCL, as it is a more edge case use, but as you say, it would be nice if it sat in an MS maintained repo and namespace. To me this feels a little like the situation with Json.Net, James Newton-King and System.Text.Json (which is part of dotnet runtime although not the BCL and is shipped as its own package).

I understand not having to maintain 2 copies of the code by embedding the required classes directly in this package, which would be the obvious way to avoid the external dependency.

Do you think @darrelmiller would consider moving the package under dotnet foundation or something, to get the advantages of their build and management processes to make the package more secure?

[baywet]

That's a great idea. I'd suggest opening another issue under that repo and closing this one since this discussion is a bit outside of this scope.

[CZEMacLeod]

Arguably this is less of a problem with any other language than dotnet as we already have other third party dependencies.

@baywet You mentioned that there are other third-party dependencies in the dotnet eco for MS Graph... Can you elaborate on that - I have not seen any others in my list but I might have missed something...

[baywet]

My sentence was poorly written. In dotnet, the only 3rd party dependency we have is UriTemplate. In other languages, Uri Templates are all 3rd party dependencies but it's less of a problem since we have 3rd party dependencies anyway from the platform and for other things (e.g. GSON for json in Java, okhttp for the http client in java, etc...)

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.