Add text explaining that some features rely on browser/OS support

[jogu]

closes #136

[c2bo]

Should we mention both, custom URL scheme and DC API?

Suggested change

	This specification assumes certain prerequisites, including browser/OS support of certain features (for example the `haip://` custom URL scheme). This means some of the mandatory clauses might not be implementable for reasons outside the implementer's control.
	This specification assumes certain prerequisites, including browser/OS support of certain features (for example support for the `haip://` custom URL scheme or the Digital Credentials API within the browser). This means some of the mandatory clauses might not be implementable for reasons outside the implementer's control.

[Sakurann]

Suggested change

	This specification assumes certain prerequisites, including browser/OS support of certain features (for example the `haip://` custom URL scheme). This means some of the mandatory clauses might not be implementable for reasons outside the implementer's control.
	The following mandatory clauses in this specification depend on browser and/or operating system support:
	- `haip://` custom URL scheme
	- Digital Credentials API
	This means there might be environments beyond the implementer's control where these clauses cannot be implemented.

[jogu]

I think there are two separate cases - if you can't do the DC API, you really can't do that whole flow at all - whereas you can support everything else in the redirect-based OID4VP flow without supporting haip://.

[Sakurann]

then would it make sense not to mention custom url schemes entirely?

Suggested change

	This specification assumes certain prerequisites, including browser/OS support of certain features (for example the `haip://` custom URL scheme). This means some of the mandatory clauses might not be implementable for reasons outside the implementer's control.
	Digital Credentials API related mandatory clauses in this specification depend on browser and/or operating system support. This means there might be environments beyond the implementer's control where these clauses cannot be implemented.

[jogu]

Discussed on this morning's WG call: The text here ends up generically applying to all 'MUST' in the spec, meaning that (e.g.) you could be compliant with a HAIP flow whilst (say) not implementing a mandatory encryption requirement. I may have misunderstood the working group intent here as that leads to a situation where interoperability would suffer.

We could instead make clear that some flows may not be implementable for reasons out of your control, and in that case the implementer can't implement that flow in a compliant way - meaning we may need some kind of "conditionality" or "optionality" for things like custom schemes that may not work in all situations. The text suggested in #240 (comment) seems like it works for custom schemes.

[Sakurann]

i made a suggestion above to go one step further and be clear that the prerequisites described apply for specific two situations: custom schemes and DC API

[jogu]

I'm wondering if this is actually covered now that #266 is in (making the haip custom url scheme optional in the redirect flow) and we have #278 in progress (that makes clear that you can pick & choose whether to do DC API or not, and same for redirect based). I'm struggling to find anything else to say.

[Sakurann]

WG discussion:

• this PR is still needed to cover both custom url schemes and DC API, even tho custom scheme haip:// is not optional
• some features (custom url schemes and DC API) rely on OS/browser features that might not be available
• potentially move this to implementation considerations

[jogu]

I've updated based on WG discussion, please re-review @c2bo @Sakurann