At this point, this is just a draft, so any declaration of purpose would be subjective until we finalize it. That being said I’m happy to answer questions about the intent of any fields you have questions about.
In general, the goal was to be as unopinionated as possible while defining a structure that could be used for a wide array of potential use cases.
Fairly simply, the idea is to allow a KYC provider to expose an endpoint that other canisters can query to see if an account is authorized to transact according to that KYC service. So going in you only need a Token Identifier, the account transacting and the amount of the transaction(sometimes KYC may be up to a certain amount).
The result can return results from KYC, AML, and some other metadata fields that the consuming service can use to decide if that user can transact or not.
Notifications can be sent from KYC Services to known providers if KYC info changes(ie. The user consumes $5k of their $25k per week allotment).
Lots to be discussed and finalized, and given that I’ve actually written one of these being considered by the working group I likely need to rewrite it given the considerations and best practices that we’ve been establishing. (ie. extensible fields are viewed with distaste, batch by default, using the ISO MUST, SHALL, MAY, SHOULD, etc).