search

openid / sharedsignals

OpenID Shared Signals Working Group Repository
47 stars 12 forks source link

added spec version to metadata #125

Closed tulshi closed 12 months ago

tulshi commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

appsdesh commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

tulshi commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

appsdesh commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent.

I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.
tulshi commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent.

I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

appsdesh commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent. I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

The main concern is where would transmitter publish version based transmitter metadata in the absence of ability to change base URL. The metadata doc is version specific, ie. every new version of the spec may have different metadata JSON. This version is not really a property of "the transmitter" as transmitters can support multiple versions.

In that case, as suggested in my option #1, should we have metadata URL as /.well-known/v1.0/ssf-configurations

tulshi commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent. I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

The main concern is where would transmitter publish version based transmitter metadata in the absence of ability to change base URL. The metadata doc is version specific, ie. every new version of the spec may have different metadata JSON. This version is not really a property of "the transmitter" as transmitters can support multiple versions.

In that case, as suggested in my option #1, should we have metadata URL as /.well-known/v1.0/ssf-configurations

Based on the content of section "6.2", the "/.well-known/ssf-configuration" needs to be inserted between the host component and the path component of the issuer. So if you have a Transmitter that supports, say v2.0 of the spec, then you can define the issuer to be "https://transmitter.myco.com/v2.0". The well-known URL will be: "https://transmitter.myco.com/.well-known/ssf-configuration/v2.0". Does that work? This does not require us to specify anything in the draft.

appsdesh commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent. I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

The main concern is where would transmitter publish version based transmitter metadata in the absence of ability to change base URL. The metadata doc is version specific, ie. every new version of the spec may have different metadata JSON. This version is not really a property of "the transmitter" as transmitters can support multiple versions. In that case, as suggested in my option #1, should we have metadata URL as /.well-known/v1.0/ssf-configurations

Based on the content of section "6.2", the "/.well-known/ssf-configuration" needs to be inserted between the host component and the path component of the issuer. So if you have a Transmitter that supports, say v2.0 of the spec, then you can define the issuer to be "https://transmitter.myco.com/v2.0". The well-known URL will be: "https://transmitter.myco.com/.well-known/ssf-configuration/v2.0". Does that work? This does not require us to specify anything in the draft.

  1. Your proposal "https://transmitter.myco.com/v2.0" will be at odds with RFC8615.
  2. I feel, another option like https://transmitter.myco.com/.well-known/ssf-configuration/v2.0 should be listed in the spec, similar to 6.2.1 that talks about issuer1 etc. else issuer definition and version definition in the URL will collide.
tulshi commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent. I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

The main concern is where would transmitter publish version based transmitter metadata in the absence of ability to change base URL. The metadata doc is version specific, ie. every new version of the spec may have different metadata JSON. This version is not really a property of "the transmitter" as transmitters can support multiple versions. In that case, as suggested in my option #1, should we have metadata URL as /.well-known/v1.0/ssf-configurations

Based on the content of section "6.2", the "/.well-known/ssf-configuration" needs to be inserted between the host component and the path component of the issuer. So if you have a Transmitter that supports, say v2.0 of the spec, then you can define the issuer to be "https://transmitter.myco.com/v2.0". The well-known URL will be: "https://transmitter.myco.com/.well-known/ssf-configuration/v2.0". Does that work? This does not require us to specify anything in the draft.

  1. Your proposal "https://transmitter.myco.com/v2.0" will be at odds with RFC8615.
  2. I feel, another option like https://transmitter.myco.com/.well-known/ssf-configuration/v2.0 should be listed in the spec, similar to 6.2.1 that talks about issuer1 etc. else issuer definition and version definition in the URL will collide.

Note that the "https://transmitter.myco.com/v2.0" is the issuer value, and not the well known URL. The well-known URL will be https://transmitter.myco.com/.well-known/ssf-configuration/v2.0 based on how section 6.2 of our SSF draft specifies the well known URL to be constructed. Note that "v2.0" is just an example. A Transmitter can choose the iss value: "https://transmitter.myco.com/best-version", and the well-known URL in that case will be "https://transmitter.myco.com/.well-known/ssf-configuration/best-version".

If I read the part of RFC8615, I am unable to understand how this scheme conflicts with that RFC. Please clarify.

appsdesh commented 12 months ago

This does not address the case where Transmitter supports multiple versions of the spec

As we discussed a service offering multiple versions will use different metadata for each version it supports

We have a single metadata URL /.well-known/ssf-configurations defined in the spec. In case of multiple version support, the transmitter should be able to publish version specific URLs.

Can the transmitter base URL be different for Transmitters supporting different versions? e.g. "transmitter1.myco.com/.well-known/.../" and "transmitter2.myco.com/.well-known/..."?

This is an SSF versioning concern, not really related to the base URL. Hence the solution should not be base URL dependent. I propose following option -

  1. Bake in the version in the well-known URL
  2. /.well-known/ssf-configurations will always show the latest version then transmitter supports. Receivers can fetch earlier versions by query params etc.

I'm not sure how this will help Receivers that need to work with a specific version. Is the intent here that Receivers should be able to discover a particular version supported by the Transmitter? If so, it will require a lot more structure around how specific versions can be discovered. The approach the current PR takes is the discovery of a specific version the Transmitter supports is outside the scope of this draft. My suggestion to use different domain names / base URLs, is similar to the option 1 you are suggesting.

The main concern is where would transmitter publish version based transmitter metadata in the absence of ability to change base URL. The metadata doc is version specific, ie. every new version of the spec may have different metadata JSON. This version is not really a property of "the transmitter" as transmitters can support multiple versions. In that case, as suggested in my option #1, should we have metadata URL as /.well-known/v1.0/ssf-configurations

Based on the content of section "6.2", the "/.well-known/ssf-configuration" needs to be inserted between the host component and the path component of the issuer. So if you have a Transmitter that supports, say v2.0 of the spec, then you can define the issuer to be "https://transmitter.myco.com/v2.0". The well-known URL will be: "https://transmitter.myco.com/.well-known/ssf-configuration/v2.0". Does that work? This does not require us to specify anything in the draft.

  1. Your proposal "https://transmitter.myco.com/v2.0" will be at odds with RFC8615.
  2. I feel, another option like https://transmitter.myco.com/.well-known/ssf-configuration/v2.0 should be listed in the spec, similar to 6.2.1 that talks about issuer1 etc. else issuer definition and version definition in the URL will collide.

Note that the "https://transmitter.myco.com/v2.0" is the issuer value, and not the well known URL. The well-known URL will be https://transmitter.myco.com/.well-known/ssf-configuration/v2.0 based on how section 6.2 of our SSF draft specifies the well known URL to be constructed. Note that "v2.0" is just an example. A Transmitter can choose the iss value: "https://transmitter.myco.com/best-version", and the well-known URL in that case will be "https://transmitter.myco.com/.well-known/ssf-configuration/best-version".

If I read the part of RFC8615, I am unable to understand how this scheme conflicts with that RFC. Please clarify.

Thanks, the example helps!