Claims based access control, supported attributes

Question

I developing an app where I get information from the user's access token. Specifically, the user claims.
The API documentation for retrieving that info specifies that there are several possible value types.
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-claim_security_attribute_v1

For the sake of testing I've been working in a sandbox to work with different claim types: string values, boolean, integer work fine.
But for the life of me, I cannot figure out how to use a SID as claims type.
There are attributes in AD which are SID.
I even extended my schema with a dummy SID attribute which I assigned to the user class.
I verified in ADSI Edit that I can edit the dummy attribute in users via attribute editor.
But no matter what I do, there doesn't seem to be a way to use SID attributes in a user claim.
When I try to add a claims type, I can only choose from a fixed list that doesn't seem to support SID or really anything else but string, int and bool.

So that leaves me with 2 questions which I hope someone can answer:

1. is it documented what the requirements or restrictions are for attributes that are used in claims types?
2. is it possible at all to work with SID claims types, or is this a case of the low level win32 API simply supporting more possible data types than are supported by Active Directory claims types?

Answer 1

At this point I'm also updating this thread in case someone else ever asks the same question :)

This piece of documentation suggests that certificate based claims can only be unicode strings
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/f062ba4d-21f4-4c71-86b2-cf77db663755

But it is irrelevant where the claims come from because, following that trail of breadcrumbs leads to this:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/252d7e10-eaf8-44e9-8b8d-205b384f5782
No matter where the claims come from, the spec says clearly that the only datatypes that are supported are:

1. Int64Values
2. Uint64Values
3. StringValues
4. BooleanValues

So I think I have enough evidence that the win32 API for getting claims information from the user token via GetTokenInformation doesn't match the Directory Services specification.
I'm still interested to hear from others if they have reason to believe otherwise.
My guess is that the GetTokenInformation information is simply based on possible attribute value types, and Directory Services simply uses only a subset of those for processing claims.

Answer 2

From this page it -seems- as if this is indeed a case of the API being more flexible than the API supports.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/dacx/how-to-set-up-a-claim-type

There are 3 possible sources for claims: AD, TransformationPolicy, and Certificates
For AD values (and by extention those from TransformationPolicy because they are basically sourced from another domain so logically they too start as AD claims)
I managed to create claims based on custom attributes that I added to the schema, but only for attributes that are integer or string for example. No SID. This makes sense, but is still no assurance concerning claims that come from a certificate.

msDS-ClaimAttributeSource must contain an attribute that has one of the following syntaxes:
String: 2.5.5.1, 2.5.5.12, or 2.5.5.15
Integer: 2.5.5.9, 2.5.5.16, or 2.5.5.2
Boolean: 2.5.5.8

For certificate sourced claims there are no outright requirements specified other than

cn and display-Name must be unique
msDS-ClaimPossibleValues cannot be specified if your claim is sourced from an OID
msDS-ClaimAttributeSource cannot be specified