# WG Meeting: 2025-05-20
## Agenda
- Cancel meeting during Identiverse?
- Working Group Last Call
- Questions about Receiver endpoint auth (https://github.com/openid/sharedsignals/issues/258)
- Proposal to add interop profile to the last call

## Attendees
- Atul Tulshibagwale (SGNL)
- Tushar Raibhandare (Google)
- Shayne Miel (Cisco)
- Yair Sarig (Omnissa)
- Apoorva Deshpande (Okta)
- John Marchesini (Jamf)
- Jen Schreiber (Workday)
- Sean O'Dell (Disney())

## Notes
### Cancel the meeting on June 3rd?
- Agreed

### WGLC
- Last date to respond: EOD on 5/27

### Recever Endpoint Auth
- We talk about the authorization / authentication of the Transmitter endpoint
- In PUSH, the receiver owns it, so how is it authenticated?
- Can the receiver push API have an authorization requirement?
- Is this the only authorization supported?
- (Apoorva) The current spec may lead implementers to believe that the value of the `authorization_header` is just the value part of the HTTP `Authorization` request header. If we change the format, it might break implementations
- (Tushar) We could also specify that it can be an open endpoint
- (Yair) We could add another configuration field called `authorization_header_name` which can be used in conjunction with the `authorization_header` to specify a header value other than `Authorization`
- (Shayne) Or we could just add another field called `headers`, where you could add any custom headers and their values
- (Apoorva) This is guided by RFC 8935 (section 5.1)
- (Tushar) Right now we only specify the Authorization request header value.
- (Tushar) Should OAuth be allowed?
- (Yair) If someone provides an authorization
- (Apoorva) We shouldn't add OAuth specific language here, but if a push endpoint does support OAuth it would just work.
- (Tushar) We could still clarify that the content of the `authorization_header` is just the value and not the name of the request header.
- (Sean) Providing examples would be good enough. 3 examples - OAuth, Auth header, and cert-based
- (Yair) Specifying a value without the name of the header could be confusing. Adding the header name will clarify it
- (Shayne) We do say it is the `Authorization` request header
- (Yair) but then does the value include the `Bearer` or other prefix?
- (Shayne)
- (Atul) update text to reference http Header
- (Atul) is taking the action to callout the Authorization use or non-standard use and will annotate this in the email to the larger group that this might cause backward compatiblity issues based on prior implementers implementation

### Add Interop spec to last call?
- (Apoorva) We have used this spec in the Gartner interop, so should we add it to the last call for final?
- (Jen) We had postponed it the last time we discussed, because we ...
- (Shayne)
- (Apoorva) Because most of the implementations are based on this, should we push it to final?
- (Jen) Perhaps we can do this after Identiverse?
- (Sean) How about use V1 Final as a baseline for the interop spec as a baseline?

## Action Items
- Atul to add the reference to the `Authorization` HTTP request header in section 6.1.1