# subject identifier discussion
###### tags: `sub_id`, `gnap`
> This note is for discussion only (as a starting point, to be discussed in IETF110)
## :memo: Backlog for subject identifier
### List of related issues
Approx 10% of currently open issues.
- [ ] [198 definition of a Subject in section 1.3](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198)
- [ ] [197 requesting User Information](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197)
- [ ] [178 sub_ids and different contexts](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/178)
- [ ] [171 subject identifiers as portable identifiers](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/171)
- [ ] [75 scope of subject identifiers](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/75)
- [ ] [51 user reference as an assertion](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51)
- [ ] [50 user identification items](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/50)
- [ ] [49 AS Validation of RC-presented assertions](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/49)
- [ ] [43 user information request items](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43)
- [ ] [42 use of identifiers as communication channels](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/42)
- [ ] [41 assertion format names](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/41)
- [ ] [16 bad use of subject identifier](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/16)
### Where is it used in the spec?
Currently the sub_id requirements are detailed in request [2.2](https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#section-2.2) / [2.4](https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#section-2.4) and response [3.4](https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#section-3.4), and discovery [9](https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-discovery)
```
"subject": {
"sub_ids": [ "iss_sub", "email" ],
"assertions": [ "id_token", "saml2" ]
}
```
We need to cover identifiers (+ their types) + assertions.
### Related standards (ongoing)
- Normative: [Secevent](https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06) and [SET](https://webconcepts.info/specs/IETF/RFC/8417)
- Informative
- [OpenID Connect Portable Identities](https://mattrglobal.github.io/oidc-portable-identities/)
- Maybe even [webfinger](https://www.packetizer.com/people/paulej/blog/52) and [openid discovery](https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01)
### Vocabulary
[The laws of identities](https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf) provide some useful terminology on subject (p12) / claim vs assertion (p5)
- assertion seems better for our use case: claim is used extensively in the identity space, we're focusing on informations that can be asserted by the AS. cf also issue that asks whether the AS must validate the assertion, or if it's a should.
- subject (see also [terminology](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198) which explains why it can apply to a person, an organization or a device)
> Subject: We have selected the word subject in preference to alternatives such as "entity", which means "a thing with distinct and independent existence". The independent existence of a thing is a moot point here - it may well be an aspect of something else. What is important is that the thing is being dealt with by some relying party and that claims are being made about it
## Rationale
### Why it's useful
- generic way of refering to a user known from the AS (including UMA2 like scenarii)
- consistent terminology
- independant/interoperable layer (OIDC or others)
- could enable message based interactions (but unclear right now)
### Downsides
- SECEVENT is used in a slightly different context, [push/poll based security](https://datatracker.ietf.org/wg/secevent/documents/), so there may be things we don't really need (ex: interceptor). But that's no a big problem (worst case, we ignore what's not useful).
- Need to clarify whether identifiers are [global or local](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/75): seems more realistic and privacy preserving to aim for local identifiers (which solves the issue)
### General questions
- how do we ensure uniqueness (AS level)?
- opaque? (like a UUID or equivalent) - especially if end-user != RO (don't want to leak personal details)
- which attributes (ex email, phone, etc.)? What about privacy?
- do we need to manage assertions about someone else (like: I'm the doctor for this patient)? or limited to same user?
- currently the difference between identifier and assertion is not very clear. Currently, the identifier is local to the AS, and it might be refering to an external OIDC or SAML2 identity through an assertion. but it should be much clearer. What is the purpose of an assertion? In this context, it seems that an assertion relates to some externally verified information - for instance for proof of presence based on the authentication of the RO (cf [vocabulary](#Vocabulary) too).
- can we generalize the assertions beyond OIDC/SAML2? (ZKP, [verifiable claims](https://w3c.github.io/webpayments-ig/VCTF/charter/faq.html) etc.). For instance, could be useful to know that a user is above a certain age, or that he is indeed working for a specific company (could trigger different rights). In some cases an assertion could have an expiry (ex: case of a user below a certain age, or because proofs expire). Cf proposed extension mecanism, how would that work?
- Should we define a new assertion structure, such as [subject identifier assertion](https://mattrglobal.github.io/oidc-portable-identities/#name-subject-identifier-assertio). More compact than a full id_token (maybe just iss and nonce)? But this brings yet another format, so not sure it's such a good idea.
- Do we want to express whether the information has been validated or not by the AS? Or do we just treat those as hints? or instead as validated?
- Do the fields mean the same in the request and the response? It might be that the request is a hint and the response a validated field from the AS.
### Remote RO (i.e. RO != end-user)
- How can deal with a RO that is different from the end-user?
- currently would trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4), see also [issue 197](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197)
- in case we have a rule engine, implementing roles (instead of capabilities) might help: the end-user could get a token with its sub and role(s) from the AS, and present it to the RS. It doesn't require that we know who the RO is, but it does require an account at the RS (the RO would define some role based access there, the end-user would own an account, associated to role(s), in the system)
- in case we need to interact with a remote RO, how do we reach him? not very different from the event json in SECEVENT from/to
```
// Figure 3 in SECEVENT (could be mapped to DIDComm, even if we don't care about the interceptor)
"events": {
"https://secevent.example.com/events/message-interception": {
"from": {
"subject_type": "email",
"email": "alice@example.com",
},
"to": {
"subject_type": "email",
"email": "bob@example.com",
},
"interceptor": {
"subject_type": "email",
"email": "eve@example.com",
},
},
},
```
- is it in the scope? (I think it should, but currently not totally clear in the current text)
- [DIDComm](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168) intead of events? many questions open, currently planned as an extension to GNAP core
- A simpler case would be that the RO has defined roles and that we support them as an alternative to capabilities (cf [discussion](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203) and [syntax](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/192#issuecomment-787903007)) - because that enables the management through automated rules engine, without a real interaction (not currently possible, cf section 4) - but that goes beyond the sub_id discussion
### Problems
- currently do not differentiate between end-user and RO, currently assume they're the same (cf section 4). Not clear what to do when they're different.
- complete list of possible identifiers [cf issue](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/178#issuecomment-779699682), would need to support DID URL and JWK, as well as an opaque identifier (same as reference? [issue 51](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51))
- what are the security implications of providing an assertion? (beyond its intended use, or against adversaries). For instance if RO != end-user we probably don't want to provide too much info.
### Non goals
- not trying to replace OpenID or other identity systems
## Dismissed alternatives (to be confirmed by WG)
### Global identifier
Kind of the idea behind https://idnum.global (as an example)
But:
- even if such a system existed, doesn't seem enforceable for all cases (can't stop someone from using something else)
- correlation is a potential issue for privacy (and it's really easy to get wrong, there are arguably [worse implementation ideas](https://github.com/UnifiedID2/uid2docs) than idnum)
### Email
- [should not be used](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/16#issuecomment-779685496), imo DIDComm solves some of the issues
- don't take email as an example
# Proposed changes
## Use the same structure
- The structure is called 'user' in 2.4, but 'subject' in 3.4. Suggest to harmonize.
- See also [terminology](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/198): Denis is saying it's not clear because a subject could be a device or an organisation (Denis is suggesting we change the definition, I disagree, but maybe we can clarify in the text if a section only concerns a natural person / also not totally sure we wouldn't need at some point to identify the RO, which could very well be not human, cf later in the discussion).
```
"subject": {
"sub_ids": [ ],
"assertions": [ ] // cf below, suggest array
}
```
## Clarify the difference between 'subject' request/response
- Subject in section 2 and section 3 don't have the same status. Section 2 should be taken as a hint (except if using a valid VC previously sent by the AS). Section 3 should (must?) be validated by the AS.
- Request.user = what the client tells the AS about the current user
- Request.subject = what the client asks the AS about the current user
- Response.subject = what the AS tells the client about the current user
```
// request
"subject": {
// that is what we ask to the AS
"subject_types": [ // list of ids we want ],
"assertions": [ // list of assertions we want ],
"hints": {
"self": {},
"principal": {}
}
}
```
- Are assertions part of the request? If so, what are they used for?
- I think they are (very) useful if we can use VerifiableCreds here (see below, we provide examples)
## Clarify the roles (RO vs end-user)
### Discussion
- Currently the text seems to focus on the RO role (but assumed to be the same person as the end-user). The titles leave the question unknown "2.4. Identifying the User", same in "3.4. Returning User Information". Consequently there's been debate whether this applies to the end-user or the RO (see [requesting User Information](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197)). After some thoughts, I think Denis is right, it concerns primarily the end-user. Only when the case that we know there's a distinct RO, might we also require a second subject (see for more details later, remote_owners).
- current titles should be "2.4. Identifying the end-user", same in "3.4. Returning end-user Information". Probably we'll need an additional section dedicated to the owner, in case it is distinct (sequences 1.4.3 and 1.4.4).
- should we therefore find a way to determine the role?
```
// initial idea (see later, it won't be the proposal)
"user": {
"subject_roles": {"RO", "end-user"}, // here means both, but could have only one
"sub_ids": [ ],
"assertions": [ ]
}
```
- We can map that to an intuitive intent, is it my data/service? or is it something I'm requesting from someone else? usually the end-user knows that. But from a system point of view, we might not systematically know in advance if the RO and the end-user are different. In OAuth2 and UMA2, it's pretty much hardcoded.
- some apps (marketplaces for instance, matching end-users with owners) could require an authentication of the end-user before knowing for sure. Still, they could also benefit from repeated interactions (they could get an assertion of what went on the previous occurence).
- in other cases the client knows ahead of time (like we have OAuth2 and UMA2, very distinctly oriented), just based on the very nature of the app (ex: app designed for doctors, app designed to see my banking accounts). When it is known in advance, it could be defined as part of the client instance. Something like`"principal": "self" or "remote"`.
- From the end-user perspective, self = me, remote = others.
- I don't propose to refer to end-user/RO, because it's just an intent declared by the app itself, not a validated user role. Cf also [SECEVENT 3.1: Subject Identifier Types versus Principal Types](https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-06#section-3.1) which basically explains that roles are out of scope of subject identifiers (and that's also a reason to manage it within the client instance) - notice they also call that principal, but I actually chose it for its definition ([principal = "first in order of importance"](https://dictionary.cambridge.org/fr/dictionnaire/anglais/principal)), as the owner is the most important entity for the delegation/consent.
- Discussion for principal (outdated : duplicate with remote_owners -> see Simplification)
- section 2.3: principal (optional) to declare the client intent in the request (taken as a hint by the AS, as to which sequence 1.4.x is likely to occur -> would need to be able to map precisely).
- If principal not present, the AS must assume an authentication will be necessary (what's the impact on the rest of the flow? what's the logic to decide if RO == end-user?).
- If principal "self" is indicated, it means the AS will expect end-user = RO (so 1 single subject). The sequence (1.4.1 or 1.4.2) will depend on parameters set in 2.5.
- If principal "remote" is indicated, it means that end-user != RO (note also that possibly that could still be the same individual under 2 different accounts). We'll need to find a way to differentiate between sequences 1.4.4 (just a policy) and 1.4.3 (here we need to specify who is the RO and how to get in touch)
- A possibility is to include a 3rd value `"principal": "self" or "remote" or "policy"`(not my prefered option, see next item)
- But it may be beyond the scope of the client instance, which shouldn't care how the AS deals with the RO
- Discussion for subject_roles (outdated: renamed principal -> see Simplification)
- section 2.4 (request):
- Probably would assume that the roles are unknown if subject_roles is not present
- Seems a bit redundant with the principal, so there's the risk we could have mutually incompatible values (ex: principal = "remote", subject_roles = {"RO", "end-user"}). I think we should avoid that.
- The client could include that field in a repeated interaction, looks more like a kind of assertion then (from a previous interaction). Do we need to provide some sort of proof? Seems an advanced use case.
- From discussion on section 2.3, it seems in some cases we'd need a way to describe the remote RO we're targeting. That's a second distinct subject. Ex: As a doctor, who's my patient?
- section 3.4 (response):
- The AS asserts the role(s), if it can (optional).
### Proposal
- Based on the previous discussion, here's my proposal (needs review):
- ~~**section 2.3: principal (optional), value = self/remote**. This drives the intent, and helps determine which sequence in 1.4.x is concerned.~~
- **section 3.4 (response): VerifiableCred assertion (optional)**
- Member of assertions[], fields include one or two subject_roles ("RO", "end-user") and the related sub_id, maybe an expiration (+ the rest required for a VC)
- If not provided, role associated to subject considered unknown
- **section 2.4 (request): VerifiableCred assertion (optional)**:
- support VC assertion (issued previously by the AS), that would be useful for repeated interactions. In its response, the AS might decide to reissue a new VC.
- additional requirement: we need a way to define a distinct/remote RO subject. I propose the same structure as subject, but called remote_owner.
- DIDs would be most helpful here
- sequence 1.4.3 (ex: doctor D wants to contact patient P).
- sequence 1.4.4 (ex: doctor D asks his hospital whether the patient P has consented in the system).
- generic DIDComm approach (even for sequence 1.4.4, enables flexible implementations where the rule engine could be anywhere, not strongly tied to the A physically, even if logically we respect the software-only authorization pattern in the AS). But for sequence 1.4.4 DIDs could be made optional of course.
- note that the AS would need its own DID too.
- so far I assumed the AS would send the DIDComm msg to the RO, but are there any privacy requirements here? I thought of an alternative architecture, where the AS is only a confidential dispatcher (the msg would be coming for the client, the AS wouldn't know who the ROs are for a specific dispatch), but that's unclear if it's possible (how would the decision by the RO be acknowledged by the AS?) and crypto heavy. Not a priority.
- Could even imagine later on more complex environments with multiple ROs (ex: a child wants consents from his dad and/or mum), so we could even imagine an array of ~~remote_owners~~ **principals** to be more generic (this asks the additional question of how the decision is made)
- or, and, first (first to decide wins), consensus (only for larger groups)
- could define asynchronous settings somewhere (ex timeout)
- might also provide a fallback (1.4.3 if answer, 1.4.4 after timeout)
- **request ~~remote_owners~~ principals (optional)**
- example 1: sequence 1.4.3 (the most straightforward case). We can add an automated fallback (to be defined, but similar to case 1.4.4) in case no-one answers.
- example 2: could also be useful for 1.4.4 too. I ask for the engine (ex: based on my age / the issuers need to be known from the engine), and the fallback could be async.
- but we need to avoid loops (engine -> RO -> engine -> RO -> etc.). Depends how we'd define fallback, but it must make sure that doesn't happen.
- **no response specific to the ~~remote_owners~~ principals**
- shouldn't provide any private information on the RO, for privacy and security reasons
- but errors could occur. Fallbacks handles some cases (ex: unreachable DID). But there also could be unrecoverable panics (ex: incorrect DID, automated engine panics, etc.). Would fall in the error part of the response.
- Do we need some assertions on ROs?
- useful to avoid spam: ex "I can prove he's my dad", "I can prove I'm his doctor"
- might even make sense to make it mandatory for sequence 1.4.3 I think... but how to get those in the first place? Probably an out of band mecanism to remain generic (but then making the assertion mandatory makes it hard to boostrap).
- or the AS could implement rate limits, blacklists, etc. (should the RO have a direct management endpoint for this?). In any case DID discovery is not GNAP's role.
```
// example 0: similar to the current spec (RO=end-user)
// see Simplification, probably no change at all
"user": {
"sub_ids": [ ],
"assertions": [
// expected response: VC subject_roles (here, "end-user" and "RO").
// Maybe we don't need that at all (see Simplification)
]
}
```
```
// example 1: sequence 1.4.3 (principals + async)
// proposal: example of a child asking his dad
"principal": {
"async": {
"timeout": "10min", // define what would be the format
"RO": {
"subject": { "sub_ids": [ // DID ] } // dad
}
}
}
```
```
// example 1bis: sequence 1.4.3 (principals + async)
// proposal: example of a child asking mum or dad
"principals": {
"async": {
"criteria": "or", // optional if there's only one remote RO
"timeout": "10min", // define what would be the format
"fallback": "none", // one parent need to respond, otherwise no consent is given (see Simplification too)
"ROs": [
{
"subject": { "sub_ids": [ // DID ] } // dad
},
{
"subject": { "sub_ids": [ // DID ] } // mum
}
]
}
}
```
```
// example 2: sequence 1.4.4 (principals + automated)
// proposal: automated rule engine
// use case: child wants to watch a film, but could be too young (will be checked by the engine).
"user": { // child
"sub_ids": [ ],
"assertions": [
// VC on DOB or ZKP on age (question: what's a valid issuer?)
]
}
"principals": {
"automated": true, // "automated" is optional, defaults to false (needs to be true to launch sequence 1.4.4)
"async": { // suppose the child wants to watch an adult film, the automated engine fails, but we plan a workaround (ask my parent then)
// similar to sequence 1.4.3
}
}
```
### Is everything clear?
- How we would deal with the case where the client doesn't know the principal? (cf discussion part). But I'm not sure it's such a big deal.
- We considered principal as optional. But is it really?
- For sequence 1.4.3, you need to explicitly supply the DIDs from the ROs (so it's not made by mistake)
- One could try to see if sequence 1.4.4 works by setting principal=remote and automated=true (also that means it must be well secured against potential attacks).
- Otherwise it's necessarily principal = self
So overall I think it solves the problem. In most cases, it will be self unless you have a real reason not to (meaning: you'll know it). That's also consistent with the fact that OAuth2 has so heavily focused on the self case.
CAREFUL HOWEVER: the paint isn't fresh... To be completly sure, we'd need to focus on error cases. Feedback welcome.
## Confirm the use of SET/SECEVENT
- By default, already covers account, email, phone, sub, aliases
- Aliases can provide some portability features (basically says it's the same, but probably need a specific assertion/proof for that purpose)
- Use [subject_types/subject_types_supported](https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184)
## Extend SET/SECEVENT
- Provides the flexibility if we can use the [SECEVENT registry](https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06#section-7.1). To be confirmed.
- DID URL: also need to take into account the did_methods/did_methods_supported in the request (2.2) and discovery (9). This is probably required if we ever want to use DIDComm.
- [JWK thumbprint RFC 7638](https://tools.ietf.org/html/rfc7638)
- [opaque identifier / reference](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51#issuecomment-788009502). Opaqueness is interesting as a privacy preserving scheme. Need to be unique (to the AS), randomly generated and serializable (cf [nanoid](https://zelark.github.io/nano-id-cc/) for instance)
```
// example DID
"subject": {
"sub_ids": [ {
"subject_type": "did",
"did": "did:example:123456"
} ]
}
// example JWK thumbprint
"subject": {
"sub_ids": [ {
"subject_type": "jwkthumb",
"jwkthumb": {
"e":"AQAB",
"kty":"RSA",
"n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n
91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw"
}
} ]
}
// example opaque reference
"subject": {
"sub_ids": [ {
"subject_type": "as_ref",
"as_ref": "XUT2MFM1XBIKJKSDU8QM"
} ]
}
```
## Assertions
- Assertions should/must only be about the same subject, otherwise it becomes too complex (+ cf security considerations: if subject_role is only end-user we should limit what we send about the RO)
- Seems to me saml2 assertions could be an extension (I think we should limit the core to its minimal possible scope + potential security weaknesses due to XML), and work on the extension mecanism with real cases (saml2, vc, etc.).
- Probably should be an array (named assertions), there could be distinct assertions made - labels could provide some info on the intented use. Or could be a simple index (assertion1, 2, etc.).
- Security implications should be reviewed (cf [above](https://hackmd.io/uuq0zv8kSA-VKjbvW6-x-g#Problems)) -> include in issue 135
```
// example assertions, the rest is not provided
"subject": {
"assertions": [ {
"assertion_label": "authevent",
"assertion_type": "id_token", // should we rename it so that it is clear it is OIDC? (like oidc_idtoken)
"id_token": {
"iss": "https://oidc.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
},
{
"assertion_label": "jobcred",
"assertion_type": "verifiableCredential",
"verifiableCredential":
{
@context: [ ],
id: "http://example.company.com/credentials/3732",
type: [
"VerifiableCredential",
"WorkingCredential"
],
issuer: {
id: "did:example:cityhospital"
},
issuanceDate: "2020-03-10T04:24:12.164Z",
credentialSubject: {
id: "did:example:ebfeb1f712ebc6f1c276e12ec21",
job: {type: "Doctor", specialty: "Surgeon"}
},
proof: { }
}
},
}]
}
```
# Summary
## Status and timing
I summarize here my thoughts (to be presented at IETF110). This is for discussion with the WG, editors and chairs (of course, no decision has been made / anything can be changed based on feedback, good or bad). Feedback/constructive criticism very welcome. If you don't like it, please voice it. If you do, also ;-)
Some of the proposed modifications have a big impact (especially RO vs end-user), so I'd expect feedback before writing PRs (and then of course, the exact wording would have to be validated).
I expect to be able to provide those PRs for the next interim meeting, if the WG thinks the changes make sense.
## Assumptions
- SECEVENT registry can be extended to our needs (DID, JWKthumb, as_ref)
- no global identifier
- a DID for the AS (we suppose the communication for sequence 1.4.3 will be between the AS and the ROs)
## Doesn't change
- Subject terminology (including org/device)
## Change
- We have a [pending merge PR on subject_type](https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/184)
- Title of section 2.4 and 3.4 changed (User -> end-User). This will make clear that the subject here is a natural person.
- Structure systematically called "subject" (not user)
- Same structure by value and reference (cf as_ref)
- Assertions (plural) are an array
- Modify terminology
- subject information: `local assertion by an AS about a subject.` (instead of statement asserted locally)
- several ROs?(I think it's useful), currently we assume there's only one (which makes more sense if end-user=RO of course, as in OAuth2). I think we can relax that assumption.
- And of course much of the text in the related sections...
## Add
- Terminology (is it useful?)
- Principal: `first in order of importance for granting privileges`. Note that we say first in order, because if we support delegatable tokens (macaroon or biscuit), even the end-user could grant its own subset (through its client). But of course, in the traditional sense (OAuth2/JWT), the owner is the main (and in many cases the exclusive) party here (through the AS).
- Assertion: `statement of fact, validated by the AS`. We don't use claim, on purpose. Related to the question on SHOULD/MUST for the validation.
- ~~principal in client instance (see Simplification, it's probably not useful after all)~~
- ~~remote_owners~~ principal(s) structure (see Simplification, could be called principal). Note that here the subject can be a person (sequence 1.4.3) or a machine (sequence 1.4.4), which justifies the subject terminology
- **principal(s)**: plural or singular?
- note that we can support several ROs. If so, we might need to adjust the terminology (currently it's assumed there's only one).
- DID, JWKthumb, as_ref
- DIDComm for async sequence 1.4.3 (and probably 1.4.4, even if it could be optional)
- using DIDComm also justifies a generic and optional "interact server" to manage all (sync and async) consent decisions
- I say optional because it a "functional" server, which is a part of the AS, but could be (optionally) deployed separately (+ [improves privacy, cf MVP](https://github.com/acertio/mvp_gnap_privacy))
- for sequences 1.4.1 and 1.4.2 would be a UI
- for sequence 1.4.3 would be through messaging
- for sequence 1.4.4 would be through a rule engine
## Remove
- Change the examples based on email
- Remove samlv2 from the core (maybe an extension?) - that also simplifies, no XML in the core...
## For later
- Security and privacy considerations
- Manage errors
- Aliases could help for portability (would need a proof that we own each sub_id)
- Define extensions:
- saml2 would be a good candidate for compatibility with legacy systems
- VC/ZKP assertions related to subject_role(s) (see Simplification, probably as an extension)
## What is solved (to be reviewed)
- RO vs end-user sequences (in particular sequences 1.4.3 and 1.4.4)
- Handles sync and async, including fallbacks
- Clarified the respective objectives of request/response
- Clarified what assertions could do (but see "Further simplification" - not sure it's necessary)
- Opens an avenue for portability (aliases) and operability (SSI)
- SSI would be much easier thanks to DIDComm
- note more generally that we could also handle separate accounts for the same user (1 is the end-user, the other is the RO)
- or the case where the RO is on a phone (including potential support of non HTTP flows via DIDComm). The async/fallback strategy would also help, in case the phone can't be reached.
- I think all the open items related to subject would be solved
## Further simplication
It's a very early draft. A part of what is presented here might be simplified or made optional.
Examples:
- Now that I think of simplification, **I don't even think we need `principal`. If the client provides the (optional) `remote_owners` it's enough to signal the intent.** Could call that structure `principal` (for the reasons mentioned above).
- Are several ROs something interesting?
- Do we really want VC in the core? We could manage many cases even without (for instance the repeat interaction is probably not a priority).
- The fallback policy shouldn't become complex (not like a XACML), and could even not be specified at all in the core
Of course an implementation will help validate all those new items in practice (run some code), but at first sight it seems very feasable.
## Things that need to be further specified
- use of DIDComm
- interact server (IS)
## Related but distinct issues
- support of various types of tokens (cf terminology for principal + [use case explained by Adrian](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/169) + [specify token format](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/189))
- note that an additional DIDComm interaction (as in XYZ) would be possible too (see [Issue 168](https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/168)) but that's a slightly different issue (and I'm not entirely sure how that would work yet)
Sign in with Wallet
Connect another wallet