First pass: policies member

[aarongustafson]

Based on the discussion in #40.

• @jcayzac @jgw96 @JudahGabriel @tomayac @torgo for thoughts with respect to their app catalogs and app management UIs.

[aarongustafson]

Note to @marcoscaceres: I know it says "must" (no caps) and this doc doesn’t have a conformance section, but it sounds like there is some interest in this moving forward toward becoming a spec (as opposed to being an amorphous pseudo-spec) so maybe that’s ok for now?

[jcayzac]

A URL-scheme string is defined as:

A URL-scheme string must be one ASCII alpha, followed by zero or more of ASCII alphanumeric, U+002B (+), U+002D (-), and U+002E (.).

This would make https a valid value for any field in policies.

Did you maybe mean absolute-URL-with-fragment string ?

[jcayzac]

that is resolvable within the application's [=manifest/navigation scope=]

Based on this comment I think restrictions based on scope should be dropped.

[aarongustafson]

I was writing this to say scope only applies for path-absolute URLs (e.g., starting with /) but fully-qualified URLs are totally cool (and good catch with absolute-URL-with-fragment string). Originally I’d written it with full URLs first but I thought it might be confusing that the URLS would always need to be in scope, which is not accurate. I could change it to state that it would be resolved in relation to the URL of the manifest.

[aarongustafson]

I want to capture a thread with @tomayac:

Sounds like a good idea to me, but this is very much IANAL land for me. Probably someone with experience in international online law should collaborate on this from the start (and sorry in advance if you actually are this person).

I replied:

I’m not a lawyer, but most app catalogs support these fields currently, but they manually enter that info into the app intake form. This would be a way of enabling the catalogs to automate that intake process.

And continued:

It could also provide mechanisms for browsers to surface this info similarly to how some browsers have historically, using similar content from link elements.

Thomas:

Yeah, well aware. Just making this up, but let’s say some legislations require the actual policy text vs. others being fine with just a link. The data model should be able to cater for both.

Me:

Oh, interesting. I hadn’t thought of that. If the policies exist at a single canonical URL, that seems like the best approach. It seems like duplicating that content by replicating the policy text in a manifest would potentially lead to sync issues between the documents.

Thomas:

What seems best from a data modeling point of view may not necessarily be what is required from a legal point of view. Again, I’ve no idea of this space, so encouraging looping in folks who do (internationally).

Me:

Agreed.

I also want to note that I have reached out to our in-house counsel to get their perspective on this. I expect it will take a little bit to get their feedback as I know they’re usually pretty busy, but I will report back with their take on how international regulatory bodies might view this once I receive it.

[aarongustafson]

@tomayac Initial meeting with our legal counsel went well. Like me, they were also concerned with carrying policy text in 2 places and the potential

1. for it to get out of sync (which could create legal issues), and
2. for it to confuse users if implementors are the ones presenting the policy text; linking to that text elsewhere makes it clear who that legal agreement is being made with.

They are going to dig a little more and get back to me if they come up with any concerns with this approach.

[tomayac]

@aarongustafson Thank you for taking my Twitter feedback and relaying it here. I was on vacation and ignoring GitHub; else, I would have responded here in the first place.

[marcoscaceres]

Looking good. I agree that not requiring these to be in scope is a good idea.

I just realized that in the other spec, we should add a "process a URL member" algorithm... we do it enough times that having a generic algorithm for this might make sense. We could even have a "don't enforce scope" flag specifically for these kinds of members.

[aarongustafson]

@marcoscaceres Do you want me to move the algorithm to Manifest? I can update that spec and reference it here.

[marcoscaceres]

That would be great if you could, yes!

[aarongustafson]

@marcoscaceres

Ignore 1017… I had not pulled from the manifest repo in a while and got out of sync.

Once 1018 merges, I can update this PR to reference it and (if you’re good with it) merge this PR.

[aarongustafson]

@marcoscaceres Circling back to this, should I remove the URL parsing algorithm or keep it? We nixed the changes in the Manifest itself.

[aarongustafson]

@marcoscaceres Would love to circle back on this one and close it out with a merge. How should I proceed?

[jcayzac]

@aarongustafson Could you rebase on the base branch and fix the CI problem?

FWIW I'm happy with the current draft.

[aarongustafson]

@aarongustafson Could you rebase on the base branch and fix the CI problem?

FWIW I'm happy with the current draft.

CI check is passing now. I brought back the URL parsing as well since we abandoned that in the main spec.

Requested approval from @marcoscaceres and 🤞🏻 we can merge.

[jcayzac]

@marcoscaceres what do you think of the changes now?