Add additional endpoint to provide PPID as physical device identifier#110
Conversation
Add PPID retrieval as a third endpoint
Updated documentation
|
I think a new endpoint is more work than using scopes. Scopes are the OpenId way to do this and PPID is already in #92 What is not in #92 is a "wild-card" scope like "kyc-default", or whatever we want to call it, that returns all the legacy attributes like "manufacturer" if we think the market need this and we do not care about data minimization. |
AxelNennker
left a comment
There was a problem hiding this comment.
LGTM
Maybe change API consumer to API Consumer because that is what is defined in Commonalities
https://github.com/camaraproject/Commonalities/blob/main/documentation/Glossary.md?plain=1#L27
| - the current IP address and port alloacted to the device, which must be an IPv6 or public IPv4 address | ||
|
|
||
| The API can be called by an API consumer to establish the identifier of the physical device currently being used by the mobile subscription. The information returned will depend upon the consent that the end user (i.e. mobile subscription owner) has given for that information to be provided to the API consumer. For example, if the end user has not consented to any information about their device being given, then the API consumer will receive an error in response to their request. Otherwise, the information that the end user has consented to being given will be returned. | ||
| The API can be called by an API consumer to establish an identifier for the physical device currently being used by the mobile subscription. The information returned will depend upon the consent that the end user (i.e. mobile subscription owner) has given for that information to be provided to the API consumer. For example, if the end user has not consented to any information about their device being given, then the API consumer will receive an error in response to their request. Otherwise, the information that the end user has consented to being given will be returned. |
There was a problem hiding this comment.
| The API can be called by an API consumer to establish an identifier for the physical device currently being used by the mobile subscription. The information returned will depend upon the consent that the end user (i.e. mobile subscription owner) has given for that information to be provided to the API consumer. For example, if the end user has not consented to any information about their device being given, then the API consumer will receive an error in response to their request. Otherwise, the information that the end user has consented to being given will be returned. | |
| The API can be called by an API consumer to establish an identifier for the physical device currently being used by the mobile subscription. The information returned will depend upon the consent that the end user (i.e. mobile subscription owner) has given for that information to be provided to the API consumer. For example, if the end user has not consented to any information about their device being given, then the API Consumer will receive an error in response to their request. Otherwise, the information that the end user has consented to being given will be returned. | |
There was a problem hiding this comment.
For "informative" documentation, I think "API consumer" is fine - in English, only "proper" nouns are capitalised in normal use
Using defined terms which are capitalised (i.e. API Consumer) is only required in a normative standardisation document, where the term has a defined and agreed meaning, and the capitalisation indicates that the term is being used very deliberately with that meaning intended.
What type of PR is this?
What this PR does / why we need it:
Adds an additional endpoint to provide PPID as physical device identifier
Which issue(s) this PR fixes:
Fixes #109
Special notes for reviewers:
This PR is an alternative to #92
Changelog input
Additional documentation
None