-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update API-design-guidelines for subscription #198
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sinkCredential is not explained enough.
Is it a shared secret provided by the API consumer?
Do we enforce that the shared secret is different and random enough for each subscription?
Is the sinkCredential a signed and encrypted JWT? With an aud
of sink
?
What is the value of source
? Is it the value of issuer
the the AZ metadata? Or is the source
maybe API specific (and the event still have different type
s for the same API?
I changed my mind about ACCESSTOKEN. There is not much Camara can do on enforcing security at the API consumer. |
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Improved sinkCredential description.
Rename webhook to sink for implicit subscription
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename webhook to sink for implicit subscription + accepted @PedroDiez proposals + proposal for token expiration
Thanks @AxelNennker |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- phoneNumber format should be "corrrect" (if needed at all, better use
sub
) - add Authorization Header
Co-authored-by: Axel Nennker <axel.nennker@telekom.de>
Co-authored-by: Axel Nennker <axel.nennker@telekom.de>
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to think about Access Token Expiration. Get your view @bigludo7
Several editorial comments. The whole view looks fine to me
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Co-authored-by: Pedro Díez García <pedro.diezgarcia@telefonica.com>
Updated line 1404
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shilpa-padgaonkar @AxelNennker I've accepted your proposal + changed the sentence line 1404.
@bigludo7 Thanks. There is another very small fix already proposed as suggestion in this comment by Axel #198 (comment) which will fix the missing authZ header in one of the examples. |
Co-authored-by: Axel Nennker <axel.nennker@telekom.de>
Thanks @shilpa-padgaonkar for the pointer on @AxelNennker comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM
@bigludo7 I noticed that there is a minor conflict you would need to resolve in the file which is blocking the merge. If you could kindly do this, we would go ahead and merge this PR as we have enough approvals now :) |
cd3863f
Thanks @shilpa-padgaonkar. Hope to have fixed it. |
Co-authored-by: Rafal Artych <121048129+rartych@users.noreply.github.com>
Co-authored-by: Axel Nennker <axel.nennker@telekom.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Reformulate the subscription part to align with our decision to move to CloudsEvent subscription model. This PR is aligned with the PR #189 which provide an examples.
Which issue(s) this PR fixes:
Fixes #185 #153 #149 #140
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.